Radar Scheduling

Skylattice treats radar scheduling as tracked operator intent, not as a hidden background worker.

The schedule itself lives in configs/radar/schedule.yaml, while the operating system remains responsible for recurring execution.

What This Covers

• inspect tracked radar schedules
• render Windows Task Scheduler registration details
• run a tracked schedule immediately without waiting for the next trigger
• validate that a weekly schedule keeps using the normal bounded radar scan path
• distinguish safe validation mode from the live promotion-capable operator path

Choose A Validation Mode

Use one of these operator modes on purpose:

• safe-validation: use a disposable validation clone, keep the tracked default live discovery provider in place, and add a clone-local no-promotion override before you run the weekly schedule
• live-promotion-capable: use your real working checkout with an intentional clean main worktree and normal promotion semantics

Safe validation is the recommended path for weekly proof and runbook checks.

Live promotion-capable execution is a separate operator decision and should not happen accidentally during validation review.

Both modes still require credentials for the tracked default live radar provider:

• GITHUB_TOKEN when the default provider stays github
• GITLAB_TOKEN when an operator intentionally switches the default provider to gitlab

Carry the chosen mode into the tracked weekly note so the record says which trigger method, runtime environment, promotion capability, credential prerequisites, and manual intervention points applied to that pass.

If the required token for the current default provider is not configured, stop and record the pass as blocked or not executed instead of pretending validation passed.

Recommended read-only preflight on the primary checkout:

python -m skylattice.cli doctor auth

If the default provider stays github, gh auth status is already healthy, and you intentionally want copyable exports for a validation shell:

python -m skylattice.cli doctor github-bridge --format env

Skylattice will not consume the gh login state automatically. The bridge stays explicit on purpose.

Inspect The Tracked Schedule

Use the CLI to see the default schedule and every declared entry:

python -m skylattice.cli radar schedule show

This tells you:

• which schedule is the default
• whether each schedule is enabled
• which window and limit it resolves to
• which tracked target_command it will run
• which Windows task metadata is associated with it

Render Windows Task Registration Details

Use the tracked render surface before you register anything:

python -m skylattice.cli radar schedule render --target windows-task

The rendered payload is the operator truth for Windows registration. It now includes:

• the absolute repository working directory
• the exact PowerShell action Skylattice expects the task to run
• the decoded action script, plus the encoded PowerShell command used for safe Task Scheduler registration
• the tracked trigger command, when the schedule is meant to run automatically
• helper commands to inspect, trigger, and unregister the task

The default weekly schedule renders a task that:

• starts from the repository root
• runs python -m skylattice.cli radar schedule run --schedule weekly-github
• uses the tracked weekly trigger command from configs/radar/schedule.yaml

Register The Windows Task

Recommended flow:

1. render the schedule
2. review the register_command
3. paste that command into an elevated PowerShell window only after confirming the trigger still matches your intent

For the shipped weekly example, the tracked trigger command is:

New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday -At 9am

If your local weekly cadence should be different, edit the tracked config first, then re-render the registration details.

Run A First Manual Check

Safe Validation Mode

Recommended flow:

1. create a disposable sibling or otherwise isolated clean clone
2. make the provider credentials explicit in that validation shell: use the GitHub bridge helper for github, or set GITLAB_TOKEN directly for gitlab
3. edit that clone's local copy of configs/radar/sources.yaml
4. set promotion_limit: 0 before the run so the validation clone cannot promote to main
5. commit that clone-local override so the validation clone stays on a clean main worktree
6. run the tracked weekly schedule from that clone root
7. export the validation report and promote only the report summary into a tracked weekly note
8. record the trigger method, runtime environment, promotion capability, credential prerequisites, and any manual intervention points in that weekly note

This path still exercises:

• tracked schedule intent
• trigger_mode and schedule_id provenance
• discovery, scoring, and experiment behavior
• weekly validation reporting

This path intentionally does not exercise:

• promotion pushes
• live adoption-registry mutation on the primary repo
• live direct-to-main behavior

Live Promotion-Capable Mode

Use this only when you intentionally want the normal radar path:

• start from a clean main worktree in the operator checkout
• keep the tracked promotion_limit
• do not apply the clone-local no-promotion override
• expect the normal promotion gates, rollback surfaces, and remote side effects to remain in play

Manual Check Command

Before waiting for the next scheduled time, trigger the task once yourself:

python -m skylattice.cli radar schedule run --schedule weekly-github

Or, after registration, use the rendered helper command:

Start-ScheduledTask -TaskName "Skylattice Radar weekly-github" -TaskPath "\Skylattice"

Success means:

• the run completes through the normal radar workflow
• the resulting radar run uses the tracked weekly window and configured limit
• the inspected radar run records trigger_mode=scheduled and schedule_id=weekly-github
• no hidden scheduler state is introduced inside Skylattice

Export A Validation Report

After a scheduled or manually triggered run, write a local validation report:

python -m skylattice.cli radar schedule validate --schedule weekly-github

By default, Skylattice writes the report under .local/radar/validations/.

The report records:

• which tracked schedule was validated
• which radar run was checked
• whether trigger_mode, schedule_id, window, limit, and completion status matched expectations
• whether the overall validation passed
• the tracked weekly record template path
• a suggested tracked record destination if you want to promote the result into a reviewable repo note
• whether you should carry the result forward as a safe-validation note or a live-path note

If you want to validate a specific run instead of the latest one, add --run-id <run_id>.

If you want to turn the local report into a tracked weekly note, start from the template at ops/radar-weekly-validation-template.md and copy the suggested record path from the validation output. Skylattice still keeps that promotion step manual on purpose.

Tracked examples now live under ops/radar-validations/2026-04-16-weekly-github.md and ops/radar-validations/2026-04-17-weekly-github.md.

Weekly-Cycle Validation Checklist

When validating a real scheduled weekly cycle, check:

• which validation mode you are using
• whether the required token for the current default provider was actually available at execution time
• the task is still registered under the tracked folder and name
• the task starts in the repository root instead of system32
• the created radar run records the expected weekly window
• the created radar run records the expected schedule_id and trigger_mode
• the exported validation report under .local/radar/validations/ marks the run as valid
• the tracked weekly note records the trigger method, runtime environment, promotion capability, credential prerequisites, and manual intervention points honestly
• safe validation runs keep promotion disabled in the disposable clone
• live promotion-capable runs only happen from the intended operator checkout
• any promotion or failure still flows through the normal ledger, memory, and rollback surfaces
• the repository remains clean before each scheduled run starts

Why This Stays OS-Level

Skylattice intentionally avoids a resident scheduler, daemon, or internal job queue.

That keeps recurring execution:

• local-first
• reviewable through tracked config
• explicit about operator responsibility
• separate from GitHub, which remains an audit and collaboration layer instead of runtime truth