work-items(tracker-seam): recurring-schedule mechanism presumed present in consuming repo — no entry invariant or remediation when the automation is absent

[kyle-sexton]

This was generated by AI during triage.

Context

Observed during an attended-queue pass in melodic-software/provisioning. reference/tracker-seam.md ("Recurring schedule") declares recurring items live in .github/recurring-schedule.json and are created by "the consuming repo's recurring-issues automation". Provisioning has neither the file nor any such automation — yet nothing in the skills checks for or surfaces that absence. Triage recommended (and the agent published to an issue comment) a "recurring recheck entry" before discovering the mechanism doesn't exist there; the flow dead-ends exactly where a consuming repo lacks the presumed infrastructure, and a schedule entry would be dead config nothing reads.

Proposed work

An entry invariant or documented degradation path for the recurring-schedule surface: detect the absence of the schedule file/automation in the consuming repo, warn loudly with a remediation route (e.g. /work-items:setup seeds it, or a documented bootstrap/opt-out), instead of letting skills recommend rechecks into a mechanism that isn't there.

Acceptance criteria

• Recommending or recording a recurring recheck in a repo without the recurring-issues automation surfaces the gap and a remediation route instead of silently presuming the mechanism

References

• melodic-software/provisioning#204 (the pass that surfaced it)

[kyle-sexton]

This was generated by AI during triage.

Triage notes

Verified: the tracker-seam reference documents the recurring schedule as living in .github/recurring-schedule.json, created by "the consuming repo's recurring-issues automation" — but no entry invariant anywhere checks whether that automation actually exists in the consuming repo. work-items:setup check/apply inspect the schedule file's presence and validity, but nothing verifies the automation that actually acts on due schedule rows is present — a repo can have a valid schedule file with no automation reading it, and nothing surfaces that gap. The reported failure (triage recommending a recheck entry in a repo with neither the file nor the automation) is a real, unguarded scenario.

Agent Brief

Type: Task
Summary: Add an entry invariant (or documented degradation path) that detects when a consuming repo lacks the recurring-issues automation the recurring-schedule surface presumes, and surfaces a remediation route instead of silently recommending or recording a recurring recheck into a mechanism that isn't there.

Current behavior:
Skills that touch the recurring schedule presume the consuming repo's recurring-issues automation exists and will act on schedule rows when they come due. Nothing checks for or surfaces the absence of that automation — a skill can recommend, or an agent can record, a recurring recheck entry in a repo that has neither the schedule file nor the automation, producing a schedule row nothing will ever read.

Desired behavior:
Before recommending or recording a recurring-recheck entry, the relevant skills confirm the recurring-issues automation is actually present in the consuming repo (not just that the schedule file exists or is well-formed). When it's absent, the skill surfaces the gap loudly and points at a remediation route (e.g. /work-items:setup seeding it, or a documented bootstrap/opt-out) instead of proceeding as if the mechanism existed.

Key interfaces:

• The recurring-schedule entry-invariant check — needs to distinguish "schedule file present and valid" from "automation that reads and acts on the schedule is present"
• Any skill action that recommends or records a recurring-recheck entry — needs to route through this invariant before writing

Acceptance criteria:

• A skill recommending or recording a recurring-recheck entry in a repo lacking the recurring-issues automation surfaces that gap explicitly, with a remediation route, instead of silently proceeding
• A repo that does have the automation sees no behavior change

Out of scope:

• Building the recurring-issues automation itself for repos that lack it (remediation points at /work-items:setup or a documented bootstrap, not a new automation implementation here)
• Changes to the schedule file's presence/validity checks already performed by work-items:setup check (this is about automation existence, a distinct signal)

[kyle-sexton]

This was generated by AI on operator direction.

Ratified — admitted for autonomous dispatch.

The operator delegated this ratification decision explicitly. Ratified on the basis that the item is briefed to a behavioral contract, its scope is bounded, and its classification was verified against the issue body rather than its title: it is genuinely C3 scoped/bug-fix-shaped, with no open design decision and no path/topic hard-gate surface (no dependency pins, no checksum recomputation, no declared-inviolable ground rules).

Restored to the autonomous frontier: agent-ready applied, needs-human removed.

first_drain_complete is deliberately left false. This is the lane's first cycle, with zero completions and therefore no evidence base; the autonomy contract's promotion apparatus expects an evidence predicate over telemetry, not a blanket flip. Ratifying per item admits the work that is actually verified while keeping the gate armed for future unratified intake — and demotion stays fail-closed if these items produce contrary evidence.