# S4 — cron / periodic / at

## Finding

This surface shows no observed scheduled-work labels in the spec's parity probe: zero
`cron-entry`, `periodic-script`, and `at-job` rows were found. The two rows in
`inventory.yaml` are the scheduler mechanisms themselves, because their Apple launchd plists
exist even though they are not executing work. The result is a dormant classic-scheduler surface,
not evidence that the scan was skipped.

There are two important limits to that finding. The exact `crontab -l` and `atq` commands were
run, but the execution sandbox rejected both with `operation not permitted`. Also,
`/usr/lib/cron/tabs/` is root-owned and returned `Permission denied`, and the bounded local-user
lookup failed with `eServerError`. Consequently, this run cannot prove the absence of Wolf's
personal crontab, the at queue through its authoritative CLI, or other accounts' crontabs. Those
limits are recorded as `unknown` on both mechanism rows and in the inventory coverage note.

## Answers to the dossier questions

1. Does anything still run on the classic rails?

No classic scheduled work was observed: `/etc/crontab` is absent, both periodic directory paths
are absent, the periodic binary and configuration are absent, `/var/at/jobs` contains no entries
visible in its directory listing, and the scheduled-work parity command emitted no labels. The
cron daemon reports `state = not running`; atrun is disabled and not registered. Because the two
authoritative CLI probes were sandbox-blocked, the strongest accurate conclusion is: nothing was
observed, but an absolute zero for Wolf's personal crontab and the at queue is not proven by this
run. The launchd-backed mechanisms are present as OS infrastructure; this dossier does not claim
that every possible recurring job on the Mac has moved to launchd.

2. Is periodic absent because of a local misconfiguration or an Apple platform change?

The evidence points to a platform-level retirement rather than a locally emptied directory. Both
`/etc/periodic/` and `/private/etc/periodic` do not exist; `periodic` is not found; `/usr/sbin/periodic`
and both periodic.conf paths are absent. The machine reports macOS 27.0, build 26A5378j. The only
bounded launchd filename containing `periodic` is
`com.apple.systemstats.microstackshot_periodic.plist`, which is an Apple systemstats telemetry
name, not a daily/weekly/monthly periodic tree. The consistent absence across the command,
filesystem, binary, configuration, and expected launchd names is the evidence for an Apple
platform change, not a single damaged local file.

3. Is cron a viable path for Wolf's personal recurring job today?

The evidence does not establish cron as a viable personal path on this OS. Its daemon is present,
but its launchd definition watches an absent `/etc/crontab`, and this run could not complete
`crontab -l`. For a new personal recurring job, the evidence-backed recommendation is to use a
launchd LaunchAgent through the S1 surface, where the job definition and runtime state are
explicitly represented, rather than relying on this dormant classic rail.

4. Are the cron and at daemons healthy and present even though unused?

Both backing plists and program paths exist. Cron's launchd record is readable, identifies
`/usr/sbin/cron`, and says `state = not running` with no prior run recorded; that is consistent
with an on-demand mechanism with nothing to watch. Atrun's plist identifies `/usr/libexec/atrun`,
has `Disabled => true`, and has `StartInterval => 30`; the runtime registry says the service is
not registered. They are present and dormant, not shown by this evidence to be crashing. The
queue/content caveats remain the blocked CLI probes described above.

5. Could another local account's crontab not be verified, and does that matter?

Yes. The root-owned `/usr/lib/cron/tabs/` listing was denied without sudo, so other accounts'
crontabs are not inspectable in this worker's read-only, unprivileged posture. The attempted
bounded `dscl . -list /Users UniqueID` check failed with `eServerError`, so this run also cannot
verify that Wolf is the only non-system local account. The gap matters for a total multi-account
census; it does not change the verified absence of the periodic subsystem or the observed launchd
mechanism states. It should remain a named coverage limitation for a future human-readable capture.

6. What would show that this surface stopped being empty?

The earliest signals are a non-comment line returned by the spec's `crontab -l` or
`/etc/crontab` check, a filename under `/etc/periodic/daily`, `weekly`, or `monthly`, an at job
number from `atq` or a corresponding file under `/var/at/jobs`, or a change in the two named
mechanism plist probes. The scheduled-work parity probe is deliberately set-based, so a future
line would appear under its exact raw crontab line, script filename, or at job number rather than
being hidden inside a count.

## Item dispositions

### `com.vix.cron` — keep

Keep the Apple mechanism as documented OS infrastructure. It is not a user job, has no verified
work to prune, and its dormant runtime state is explained by the absent `/etc/crontab` trigger.
Do not remove or stop it from this inventory workflow. The row's `unknown` flag is limited to the
blocked personal-crontab check and is not a claim that cron work exists.

### `com.apple.atrun` — keep

Keep the Apple mechanism as documented infrastructure. Its plist and executable remain present,
but the plist is disabled and the launchd service is not registered. There is no verified at job
to prune. The row's `unknown` flag records that the authoritative `atq` command could not execute;
the visible empty jobs directory is retained as supporting filesystem evidence, not substituted
for the blocked queue probe.

## Coverage and future action

The inventory intentionally contains no placeholder scheduled-work rows. An empty scheduled-work
set is the result of the parity command, while the two mechanism rows preserve the separate answer
that the OS still ships the machinery. If a total account-level census is required, Wolf should
provide a permitted read-only capture for root-owned cron tabs and a working direct probe for
`crontab -l`/`atq`; this worker will not use sudo or execute scheduler mutation commands.