Technical Evaluation

Architecture fit

nova-rss is a Laravel Artisan-command package with two distinct entry points: nova-rss:warm (cache warming, a scheduled job) and nova-rss:check (health reporting). v3.2.0 sharpens that separation by making warm tolerant and leaving check as the source of truth for health.
This is a good architectural direction: a scheduled cache warmer talks to third-party publishers the application does not control, so treating partial failure as success is the correct default. Exit codes on warm were previously conflating "my network/config is broken" with "one publisher is slow."

Integration feasibility

Low integration effort. One new opt-in flag (--strict), one behavioural change to exit codes, and additional log output. No migration, no schema change, no API surface change.
The only real work is auditing our own scheduler, alerting, and error-tracking configuration to confirm what we currently key off.

Technical risk

The exit-code change is a behavioural break shipped in a patch. warm previously exited non-zero when any source failed; it now exits zero unless every source fails. Anyone alerting on the command's exit status loses that signal. Correctly, it is reversible via --strict.
Version-provenance problem is the bigger risk. 3.1.1 was tagged from a working tree containing uncommitted changes, and its release notes described it as a documentation release. Packagist pins the commit to the version, so it cannot be corrected. Practically: v3.2.0 is the first release where we can know what we are running, but the underlying behaviour already shipped to 3.1.1 consumers undocumented. That is a release-hygiene failure, not a code defect, but it is a supply-chain trust signal we should weigh.
Silent degradation mode. Making partial failure a zero exit converts a loud failure into a log line. If nobody watches the log, feeds can rot one publisher at a time with the scheduler showing green.
Positive signal: 109 tests / 560 assertions and PHPStan clean. Note that the test suite evidently did not encode the exit-code contract as a documented guarantee — the gap was process, not coverage.

Key questions

Which of our services are already on 3.1.1 and therefore silently carrying this change?
Is the exit-code contract documented as public API, and is there an upgrade note calling out the change?
Does nova-rss:check detect "some sources stale/unreachable," or only "no cache at all"? If the former, warm exit codes are a redundant alert path and the risk is low.
At what log level are per-source failures emitted, and to which channel? What is the expected volume if a publisher is down for a week at our schedule interval?
Does a partially warmed cache degrade gracefully on read (live fetch / stale-while-revalidate), or does a miss surface as an error to end users?
Supported PHP/Laravel version matrix, and is this a direct dependency or transitive?

Integration Approach

Stack fit

Standard Laravel Artisan command integration: scheduler entry plus optional alerting. --strict maps cleanly onto CI/pipeline use where any failure should halt; default tolerant mode maps onto production scheduling.

Migration path

Pin ^3.2.0 explicitly. Do not target 3.1.1 — it carries the behavioural change without the documentation, the escape hatch, or the per-source logging.
Treat the effective upgrade as "any version ≤3.1.0 → 3.2.0," since the behaviour changed underneath 3.1.1 regardless.
If we currently alert on nova-rss:warm exit status, either append --strict to preserve today's semantics, or move alerting to nova-rss:check and accept warm as best-effort. Pick one deliberately; do not leave it implicit.

Compatibility

Additive flag and log lines; no deprecations or removals in this release.
nova-rss:check unchanged — any existing health dashboards keep working.
No backward-compatible way to get v3.2.0's documentation onto 3.1.1; the version is immutable on Packagist.

Sequencing

Inventory which environments resolve to 3.1.1 or 3.1.x today.
Confirm log routing and alerting destination for the new per-source error lines before upgrading.
Upgrade to 3.2.0 in staging; run a scheduled cycle with one deliberately unreachable source and confirm exit 0 plus a log entry.
Decide strict vs. tolerant per environment and encode it in the scheduler definition, not in a wiki.
Promote to production; verify dashboards still reflect real health.

Maintenance

Near-zero ongoing cost: no config changes, no data migration, no new dependencies.
Watch the changelog for the next release — a maintainer willing to tag from a dirty tree is a maintainer whose releases need reading rather than assuming.

Support

Runbook update required: the new "green but partially degraded" state needs a documented response. On-call should know that warm exit 0 does not mean all feeds are fresh, and where to look.
Support burden shifts rather than disappears — from "scheduler failure alert" to "log line nobody read." Only accept that shift if the log line is routed somewhere a human or an alert rule actually sees.

Scaling

Tolerant mode improves scaling characteristics: one slow publisher no longer poisons the whole warm cycle, so the job's runtime and success rate decouple from the slowest third party.
Per-source logging is the scaling risk: a chronically dead publisher at a 5-minute schedule produces ~288 entries/day per source. Needs log-level discipline or a dedupe/alert rule.

Failure modes

All sources down → exit 1. Correct, and correctly interpreted as our network/config problem.
Some sources down → exit 0 + log only. Silent partial staleness. Highest-likelihood operational failure.
--strict misapplied in production → reintroduces the original fragility. Ensure the flag is only set where a pipeline genuinely wants all-or-nothing.
Log blindness → the new signal exists but is never consumed.
Provenance drift → a tagged artifact that does not match a reviewed commit. Mitigated going forward by pinning to 3.2.0 and requiring a clean-tree check in our own dependency review.

Ramp-up

Minimal engineering effort — a flag and an exit-code semantic. The real effort is a short, deliberate conversation about what "healthy" means for feeds and which command owns that answer. Budget an hour of on-call and observability time, not a sprint.