[operations] devstats.lock.yml and daily-team-status.lock.yml have expired stop-time gates — silently skipped (not failed) for ~8 months

[kubestellar-hive]

Finding

Two scheduled (gh-aw generated) workflows have a hard-coded stop-time
gate that expired 8+ months ago, silently disabling them ever since,
with zero alerting:

• .github/workflows/devstats.lock.yml — GH_AW_STOP_TIME: 2026-01-16 19:38:33
• .github/workflows/daily-team-status.lock.yml — GH_AW_STOP_TIME: 2026-01-03 19:22:35

Both still run on their schedule: cron: "0 9 * * 1-5" trigger today, but
the pre_activation job's check_stop_time step compares new Date() to
the hard-coded stop time and sets activated=false once it's passed
(devstats.lock.yml:6355-6369). The downstream activation job requires
needs.pre_activation.outputs.activated == 'true' (devstats.lock.yml:51),
so the agent job that actually generates the team-status report is
skipped. The conclusion job that would otherwise post a summary or
alert also requires needs.agent.result != 'skipped'
(devstats.lock.yml:5569), so it skips too.

Net effect: every weekday run since mid-January 2026 shows as a normal
grey "skipped" run in the Actions tab — never a red ❌ — and produces no
discussion, no comment, no job summary, and no issue. This is a strictly
worse variant of the "no failure alert beyond a job summary" gap class
already tracked in this repo (#6718/#6724/#6729/#6715/#6759): those
workflows at least run and fail loudly in logs; these two have been
completely inert for ~8 months with a status that looks identical to
"nothing scheduled to do."

Why this matters

• The workflow's own description: front matter
  (.github/workflows/daily-team-status.md) says it "creates a daily team
  status reporter" — a recurring deliverable maintainers/community may
  expect — that has not run in ~8 months.
• Because the run status is "skipped" (not "failure"), none of the
  existing failure-detection tooling in this repo (or a human scanning
  the Actions tab for red X's) would catch this.
• The same stop-after: +1mo pattern likely affects other gh-aw
  generated workflows in this repo (e.g. maintainer-metrics.lock.yml,
  technical-doc-writer.lock.yml) — this issue is scoped to the two
  confirmed-expired cases found by direct inspection; a maintainer with
  gh-aw tooling access should audit the rest.

Recommendation

• Recompile/regenerate devstats.lock.yml and daily-team-status.lock.yml
  from their .md sources with an extended or removed stop-after, per
  the in-file comment: "workflow will no longer trigger after 30 days.
  Remove this and recompile to run indefinitely."
• Consider having pre_activation's stop-time check post a one-time
  alert (issue/discussion) instead of a silent core.warning, so an
  expired stop-time is visible without an Actions-log deep-dive.

Scope

• agent/operations

Filed per operations policy (confirmed via direct inspection of
.github/workflows/devstats.lock.yml and
.github/workflows/daily-team-status.lock.yml in this repo; current
date used for comparison: 2026-09-06).

— hive: agent=operations backend=copilot model=claude-sonnet-4-6

[kubestellar-hive]

Opened PR #6781 with runbooks/scheduled-workflow-monitoring.md, documenting how to distinguish a silently-skipped run (expired GH_AW_STOP_TIME gate, grey status) from a failed run (red status), for devstats.lock.yml/daily-team-status.lock.yml. This is docs-only mitigation; the workflow-side fix (bumping/removing the stop-time gate) still needs a maintainer with workflows permission, since agent tokens cannot write .github/workflows/* in this repo.

🐝 Hive Agent: operations

— hive: agent=operations backend=copilot model=claude-sonnet-5

🐝 Hive Agent: operations | Instance: hosted-kubestellar-console-4vkt | SHA: unknown