Could the cron parser, or the scheduler core, ship as a package with no dependencies?

Wolverine chose Cronos for its recurring messages (JasperFx/wolverine#4307) with a stated reason: "a parser, not a scheduling engine; MIT, zero transitive deps, correct DST". Quartz's parser is at least as capable — H hashing, wrapping ranges, CronFormat.Unix, macros, the Vixie day-union, a builder — but it ships inside an assembly that references five Microsoft.Extensions.* packages and targets net10.0 alone, so a library that wants only the expression cannot take it.

This issue is a report, not a change. It answers, with sizes and a recommendation, two questions:

1. Quartz.Cron — a zero-dependency parser package. Verified starting point: CronExpression.cs, CronExpressionBuilder.cs, CronFormat.cs, CronMacros.cs, CronExpressionConstants.cs plus UnixCronRewriter, TimeZones, TriggerConstants, BitUtil, StringExtensions, SerializationInfoExtensions are ~5,000 lines over 11 files and BCL-only once Throw stops dragging the ADO exception namespace (5 of its 30 members are used) and TimeZones inlines the Mono check that is its only path to Microsoft.Extensions.Logging. CronExpression already computes next/previous/invalid times from a DateTimeOffset alone. Commit 7ff7284f20 (2026-08-30) anticipated exactly this split "mechanically rather than by redesign". Open questions the report must settle: the public surface; whether the namespace stays Quartz with [TypeForwardedTo] from Quartz.dll (binary and source compatible); the target-framework question — a parser that only targets net10.0 serves nobody Cronos serves, so net8.0;net10.0 against the repository's single-target rule and the polyfill discipline that would cost; the public-API baseline mechanics (a new baseline file, a moved block in Quartz's); the MON/2 message naming RecurrenceScheduleBuilder; who would consume it (Wolverine, MassTransit, TickerQ, Brighter, Aspire).

2. Quartz.Core — whether the scheduler minus DI/hosting/health could be a minimal-dependency package. Verified: Extensibility/, Matchers/, Queries/, Impl/Calendar/, Impl/Recurrence/, every builder, IJob/IScheduler/ITrigger/IJobDetail/JobDataMap, IJobStore, IThreadPool reference no Microsoft.Extensions.*, no System.Text.Json, no System.Data; Core/ uses Microsoft.Extensions.Logging directly in 9 of 20 files (CoreLog is a LoggerMessage partial) and RAMJobStore in one; Configuration/ is 28/44 M.E.-bound. So a Quartz.Abstractions is mechanical and a Quartz.Core that drops logging is a redesign. The report sizes both and says which, if either, is worth doing and when.

Output: a written report with a recommendation and rough sizes, filed here for a decision. No code in this issue.