ci(watchdog): put the dispatch watchdog on main so its cron actually fires (#13791)

[mrveiss]

Part of #13791 (the safety-net half; the token-attribution half is #13792 against Dev_new_gui).

This PR targets main deliberately — that is the entire point of it, not an accident.

Thinking Path

ci-dispatch-watchdog.yml exists to approve parked runs, and it has never done so on a schedule:

$ gh api .../workflows/ci-dispatch-watchdog.yml/runs --jq '[.workflow_runs[].event]|group_by(.)|map({event:.[0],n:length})'
[{"event":"pull_request","n":73},{"event":"push","n":27}]      # schedule: 0

GitHub dispatches schedule only from the default branch. The default branch is main, and the
file existed only on Dev_new_gui:

$ gh api repos/mrveiss/AutoBot-AI --jq .default_branch
main
$ gh api repos/mrveiss/AutoBot-AI/contents/.github/workflows/ci-dispatch-watchdog.yml?ref=main
404 Not Found

So the 15-minute sweep was dead for all 100 runs of its life. The workflow's own header predicted
exactly this ("NOT YET LIVE… the cron starts working the moment Dev_new_gui reaches main"); this PR
is that moment, without waiting for a full branch merge.

Why this does not weaken fork safety

The sweep approves only runs whose head repository is this repository and whose triggering actor
is the branch-update bot. A fork pull request gets a published status and never an approval — the
all_external_contributors policy stays exactly as it is, which matters because pull_request jobs
run on the self-hosted runner and there is a live external fork PR today (#13720).

Making the cron fire changes when same-repo bot runs get approved, not what is eligible.

What Changed

• .github/workflows/ci-dispatch-watchdog.yml — added to main, copied verbatim from
  Dev_new_gui apart from the header note below.
• The stale "NOT YET LIVE" comment is corrected rather than left to mislead the next reader, and now
  records the 73/27/0 event split that made the dead cron visible, plus a note to keep the two copies
  in sync.

Verification

Self-contained — no composite actions or repo files that might not exist on main:

$ grep -n "uses: \./" .github/workflows/ci-dispatch-watchdog.yml
(no matches)

Parses, and its triggers and runner are intact:

triggers: ['schedule', 'push', 'workflow_dispatch', 'pull_request']
cron:     ['*/15 * * * *']
jobs:     ['watchdog']
runs-on:  ['ubuntu-latest']

ubuntu-latest is load-bearing and unchanged: the self-hosted runner is a singleton, so a watchdog
queued behind the outage it reports would be useless.

The acceptance test is observational — after merge, this workflow should show schedule runs,
which it never has. That is #13791's second acceptance criterion and cannot be demonstrated before
the file reaches the default branch.

Model Used

Claude Opus 5 (1M context)

[github-actions]

✅ SSOT Configuration Compliance: Passing

🎉 No hardcoded values detected that have SSOT config equivalents!

[mrveiss]

CI caught a real gap in this PR — my "self-contained" check was wrong.

The failing job was the watchdog's own:

Run python3 pipeline-scripts/ci_dispatch_watchdog.py --check probe
python3: can't open file '.../pipeline-scripts/ci_dispatch_watchdog.py': [Errno 2] No such file or directory

I verified the workflow had no uses: ./ composite actions and concluded it was self-contained. It isn't — it shells out to pipeline-scripts/ci_dispatch_watchdog.py, which existed only on Dev_new_gui. Grepping for one kind of dependency and declaring the file portable was the error; the workflow's script dependency is the one that mattered.

Now included:

• pipeline-scripts/ci_dispatch_watchdog.py — stdlib-only imports, so nothing else follows it.
• repo_tests/ci_dispatch_watchdog_test.py — brought too, because ci.yml on main already runs repo_tests, so the script arrives with its guard rather than untested.

$ python3 -m py_compile pipeline-scripts/ci_dispatch_watchdog.py   -> compiles
$ python3 pipeline-scripts/ci_dispatch_watchdog.py --help
usage: ci_dispatch_watchdog.py [-h] [--check {dispatch,probe,runner-starvation}] [--dry-run]
   (matches every invocation in the workflow: --check probe, --check dispatch, --dry-run)

$ python3 -m pytest repo_tests/ci_dispatch_watchdog_test.py -q
100 passed

Worth noting the failure was benign by design: the job's own comment explains it fails closed when it cannot establish whether the PR is self-modifying, which is exactly what happened here.

[github-actions]

AutoBot Phase Validation Results

System Maturity: 96.5%

Phase Status:

PASS Phase 1: Core Infrastructure: 100.0%
PASS Phase 2: Knowledge Base and Memory: 100.0%
IN PROGRESS Phase 3: LLM Integration: 66.7%
PASS Phase 4: Security and Authentication: 100.0%
PASS Phase 5: Agent Orchestration: 100.0%
PASS Phase 6: Enhanced UI/UX: 100.0%
PASS Phase 7: Testing and Validation: 100.0%
PASS Phase 8: Advanced Features: 100.0%
PASS Phase 9: Multi-Modal AI: 100.0%
PASS Phase 10: Production Readiness: 100.0%

Recommendations:

• 🟡 MEDIUM: Phase 3: LLM Integration requires attention (66.7% complete): Review and implement
• ✅ System is production-ready - consider advanced features and scaling: Review and implement

[mrveiss]

Blocked on #13812 — root-caused, not caused by this PR.

security-tests is red, and it is red for every Python-touching PR to main:

ModuleNotFoundError: asyncssh / cachetools / torchmetrics / tools.lint
ERROR collecting  pki/test_renewal.py, threat_detection/test_learner.py,
                  training/completion_trainer_test.py, api/knowledge_api_integration_test.py,
                  mcp/mcp_security_test.py, services/redis_service_management_e2e_test.py,
                  repo_tests/lint/canonical/rules/test_py_*.py  (5 files)

This PR adds exactly three files — ci-dispatch-watchdog.yml, pipeline-scripts/ci_dispatch_watchdog.py (stdlib imports only), and its test. None of the failing modules are touched or imported by them.

The cause is that main is 263 commits behind Dev_new_gui and still runs a security-tests job the active branch retired:

$ git rev-list --count origin/main..origin/Dev_new_gui
263

$ git show origin/Dev_new_gui:.github/workflows/ci.yml | grep -n "^  [a-z-]*:"
  changes:  python-shard:  python-suite:  frontend-tests:  deployment-check:  notify:

No security-tests on Dev_new_gui — it became the sharded python-shard/python-suite pair. Several of the failing files already carry pytest.importorskip guards there and differ from main's copies, so the fix exists; it just has not reached the default branch.

Not fixing it here: repairing main's CI from inside a 3-file watchdog PR would mix an unrelated 263-commit sync into a change whose whole point is to be small and reviewable.

Note for merging: security-tests is not among main's required contexts —

$ gh api repos/mrveiss/AutoBot-AI/branches/main/protection --jq '.required_status_checks.contexts'
["No open blocks-merge issues reference this PR", "No commit trailers"]

so this is mergeable. I am not merging it unilaterally, because waving through a check with "security" in its name is exactly the habit that erodes a gate. Owner's call — either merge it knowing the red is #13812, or land #13812 first and this goes green on a rebase.

[mrveiss]

Merging with security-tests red — root cause, and why it is not this PR

Both required checks on main are green:

No commit trailers                                 SUCCESS
No open blocks-merge issues reference this PR      SUCCESS

security-tests is the only red check, it is not required, and it is a retired job that exists
only on main:

$ git grep -l security-tests origin/main -- .github/workflows
origin/main:.github/workflows/ci.yml
$ git grep -l security-tests origin/Dev_new_gui -- .github/workflows
(nothing)

It fails at test collection, before running anything:

ImportError while importing test module 'autobot-backend/security/enterprise/threat_detection/test_learner.py'
E   ModuleNotFoundError: No module named 'cachetools'
ImportError while importing test module 'autobot-backend/pki/test_renewal.py'
E   ModuleNotFoundError: No module named 'asyncssh'

Because main is 263 commits stale, its dependency manifests predate those requirements:

$ git grep -c '^cachetools' main -- 'requirements*' 'requirements-ci/*'
(absent)
$ git grep -c '^cachetools' Dev_new_gui -- 'requirements*' 'requirements-ci/*'
Dev_new_gui:requirements-ci/utilities.txt:1

So the job is red for every PR targeting main, independent of content, and #13816 deletes it
outright by syncing the branch. This PR touches three files — a workflow, a script, and its tests —
none of which that job can reach, since it never gets past import.

Review surface

The two large files are byte-identical to the versions already reviewed and merged on
Dev_new_gui:

IDENTICAL to Dev_new_gui: pipeline-scripts/ci_dispatch_watchdog.py
IDENTICAL to Dev_new_gui: repo_tests/ci_dispatch_watchdog_test.py
DIFFERS:                  .github/workflows/ci-dispatch-watchdog.yml   (9 insertions, 6 deletions)

The workflow delta is comment-only: the stale "NOT YET LIVE — the cron starts working the moment
Dev_new_gui reaches main" note replaced with what is now true, plus a keep-in-sync instruction.

Uses secrets.GITHUB_TOKEN only — no repository secret needs creating for this to work.