Restore truthful coverage and bounded test execution across supported branches

[rmcdaniel]

Problem

Stable release 1.0.80 replaced a Laravel-version-specific routing trait with a package-owned method-dependency resolver so Laravel 9 through 13 can use workflow and activity injection. The compatibility jobs pass, but the released commit still reports failing Codecov statuses: 99.52% project coverage and 76.08% patch coverage. The uncovered branches are compatibility-sensitive behavior in the new resolver rather than incidental scaffolding.

Acceptance criteria

• Add focused resolver tests for after-resolving attribute callbacks, missing reflected methods, contextual-attribute resolution, enum/default handling, already-supplied class parameters, contextual-attribute lookup, and self/parent parameter type resolution.
• Preserve the Laravel 9 through 13 workflow/activity compatibility matrix and prove version-dependent container behavior without application aliases or framework source patches.
• Restore 100% project and patch coverage on the stable 1.x target branch.
• Do not weaken, bypass, or reclassify the existing coverage requirement.

Completion

Delete when the stable 1.x target branch covers every package-owned resolver branch and its public project and patch coverage checks both pass at 100%.

Consolidated scope

Stable 1.x isolation, bounded waits, and real v2 coverage are one test-reliability and coverage contract.

#430: Raise real v2 coverage from its branch baseline to 100%

Problem

Branch-scoped Codecov evidence currently reports 53% coverage for v2. The branch's contributor guidance treats 100% unit coverage as the target, but v2 needs its own measured path to that target rather than inheriting or displaying master data.

The immediate false-badge correction is isolated in #431 so it can land without waiting for the broader test campaign.

Required outcome

• Measure v2 coverage against the complete intended production source set and publish an in-repository machine-readable summary.
• Establish a non-decreasing branch coverage ratchet from the honest v2 baseline.
• Identify uncovered executable paths by component and add behavior-focused tests until v2 reaches 100% line coverage.
• Keep the measured source set stable while raising coverage.
• Do not reach the target by excluding production files or lines, weakening the measured source set, copying master data, or suppressing uncovered executable code.
• Make ordinary v2 changes fail when they reduce the accepted branch baseline.
• Keep Codecov uploads bound to the tested v2 commit and branch.
• Required public CI remains green at each incremental landing.

Evidence

As observed on 2026-08-24, the v2-qualified Shields/Codecov badge reports 53% while the unqualified default-branch badge reports master at 100%.

#433: Make 1.x feature-test Watchdog isolation effective

Problem

The stable 1.x feature harness added WORKFLOW_WATCHDOG_ENABLED=false only to child queue-worker environments in commit 726734169120c669964f7363ef063c7062b2e2b5. The package service provider publishes src/config/workflows.php but does not load or merge it. In a fresh feature-test job with no published config/workflows.php, the listener reads config("workflows.watchdog.enabled", true) and therefore still enables Watchdog; the environment variable is never consumed. A green rerun does not demonstrate that the intended isolation is active, so the prior 12-minute MySQL hang can remain intermittent.

Acceptance criteria

• Make the stable feature harness explicitly disable Watchdog in each spawned worker without depending on a previously published config file or test execution order.
• Add a focused regression that boots the same child-worker application shape and proves a queue Looping event cannot schedule Workflow\Watchdog while isolation is enabled.
• Preserve the separate real database-queue Watchdog coverage, including the greater-than-255 fresh-tick regression.
• Run the full MySQL and PostgreSQL feature jobs from clean checkouts and keep bounded workflow-wait diagnostics.

Delete when

Delete when the landed 1.x harness has direct automated evidence that child workers cannot start background Watchdog chains and clean-checkout MySQL/PostgreSQL qualification passes.

#434: Bound workflow waits across the 1.x feature suite

Problem

Commit 726734169120c669964f7363ef063c7062b2e2b5 introduced a diagnostic waitForWorkflow() helper after one feature case consumed the full 12-minute CI timeout, but only two StateMachine waits use it. The same master ref still has 66 unbounded workflow-running loops across 25 feature files. Any stranded workflow in those paths can spin until the job-level timeout, hiding the workflow ID, status, logs, and exception count that the new helper reports.

Acceptance criteria

• Replace unbounded feature-suite workflow-running loops with the shared bounded wait helper or an equivalent deadline-aware helper that preserves tests requiring intermediate interaction.
• Keep intentionally stateful waits explicit, bounded, and diagnostic; do not turn assertions about signal, timer, retry, or child-workflow states into simple completion waits.
• Add focused regression evidence that a workflow which never leaves running state fails within its local deadline and reports actionable workflow diagnostics.
• Run the complete stable MySQL and PostgreSQL feature jobs from clean checkouts.

Delete when

Delete when no stable feature test can wait indefinitely for a workflow transition and timeout regressions prove failures terminate locally with actionable diagnostics.

[rmcdaniel]

Current status: Deferred to a recorded product milestone

This work is intentionally scheduled for the product milestone recorded in the issue. No maintainer action is pending.