StepHandler abstraction (app/Support/VideoWorkflow/StepHandlers/) plugs
into WorkflowEngine without coupling it to how any given step type is
actually executed:
- ScriptGenerationHandler: builds a prompt from the project's title/
description (or an explicit outline/tone/keywords/target length in
step input), generates via an active OpenAI AiProvider, stores the
result as a 'script' asset.
- TtsVoiceoverHandler: voices step.input.text, or falls back to the
project's latest script asset, via an active ElevenLabs AiProvider;
voice_id/model_id are configurable per step. No direct "speed"
control — ElevenLabs' base TTS endpoint doesn't expose one.
RunWorkflowStepJob resolves a step's handler by type and runs it on
the queue, matching the existing PublishPostJob pattern (including a
stale-dispatch guard: no-op if the step isn't 'in_progress' anymore).
UI, under its own /video-projects routes and nav entry — separate
from /projects per the earlier decision:
- VideoProjects/Index (#43): list projects with status and step
progress, create new ones.
- VideoProjects/Show (#44): start a project from a WorkflowTemplate or
a hardcoded default 8-step pipeline; per-step Run/Approve/Reject/
Retry/Skip actions; auto-queues the next step after any transition
when a handler exists for its type (steps with no handler yet just
sit in_progress rather than auto-failing); lists project assets.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Posts get a nullable image_url. WordPressPublisher now downloads it
and uploads it to WordPress's media endpoint before creating the
post, setting it as featured_media — and rejects publishing (without
touching status) if a blog post has no image set, mirroring the
existing title requirement. Every other network treats it as optional.
Not enforced at save time, same as title — you can still draft an
incomplete WordPress post, it just can't be published until an image
is set. Exposed through the UI form (with a thumbnail/""missing""
indicator in the table), the JSON API, and the Python CLI wrapper.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Skip if the post is no longer status=publishing when the job runs, so
a stray duplicate (e.g. clicking Publish twice while no worker was
running) can't publish the same post to WordPress a second time.
Also root-caused a stuck-in-"publishing" post reported live: the
queue worker started manually last session was a bare background
process, not a real service, and had died. Replaced it with a
systemd unit (muninn-queue-worker.service, enabled + running) so
the Publish button keeps working across reboots/restarts.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Introduce Publisher/PublisherManager (WordPress + Reddit implementations)
so publishing logic is shared between the CLI, the queue, and future
network integrations. Add a "Publish" button on the Posts page that
dispatches PublishPostJob instead of blocking the request — Reddit's
publisher shells out to the existing Playwright sidecar and can take
tens of seconds, so it can't run synchronously in a web request.
Adds a `target` field (e.g. subreddit) and `publishing` status to Post,
plus a `publish_error` field so failures surface in the UI. Refactors
posts:publish to delegate to WordPressPublisher without changing its
CLI output contract (existing tests pass unchanged).
Also fixes two bugs found along the way: UpdatePostRequest was silently
dropping `published_url` from PATCH requests (never in its validation
rules, despite AI_API.md documenting it), and three Livewire index-page
tests were broken by the earlier auth change (never re-run after adding
the `auth` middleware) since they hit routes via HTTP without a logged-in
user.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
