Modified auto_progress() to complete the Apply phase immediately after
transitioning from Execute to Apply, since Apply is a metadata transition
with no LLM processing. This ensures `plan execute` drives the plan to
the terminal `applied` state when the automation profile permits (ci,
full-auto profiles with auto_apply < 1.0).
Extracted `_complete_apply_if_queued()` helper that consolidates the
Apply-completion pattern (start_apply + complete_apply) into a single
method with error recovery (calls `fail_apply` on failure) and async-job
guard (skips inline completion when async execution is enabled to avoid
orphaning enqueued jobs). Used by `auto_progress()`,
`lifecycle_apply_plan()`, and `try_auto_run()`.
Added PlanLifecycleService.try_auto_run() that drives plans through all
lifecycle phases (strategize → execute → apply) when automation-profile
thresholds allow automatic progression. Each phase checks the profile's
auto_* threshold before proceeding; a threshold of 1.0 stops the plan at
that phase boundary for human approval.
Fixed `lifecycle-apply` CLI leaving plans stuck in `apply/queued` without
completing. The command now calls `_complete_apply_if_queued()` when the
plan is in Apply/queued, driving it to the terminal `applied` state.
Fixed stale RICH output in `lifecycle_apply_plan` that printed
"Plan is now in Apply phase (queued)" after the plan had already reached
terminal `applied` state; now branches on `plan.is_terminal`.
Additional fixes:
- SQLite UNIQUE constraint violation in LifecyclePlanRepository.update():
added session.flush() after clear() on child collections (project_links,
arguments, invariants) before re-inserting rows
- Added 'state' alias in _plan_spec_dict() JSON output for spec §Example 7
jq compatibility
- Updated plan execute and lifecycle-apply reference documentation
Refs: #753
Luis Mendes
59be111e1d