Auto-publish journey.yaml to Skene Cloud on first analysis

[bmichele]

Summary

First-time Skene TUI users who link a workspace and run journey analysis land on an empty Customer Journey canvas after following the visualization's link to skene.ai (they haven't pushed journey.yaml yet). This change auto-publishes the generated journey.yaml right after analysis, so the cloud canvas is populated by the time they click through.

It only fires when both hold:

1. running with the skene provider (TUI linked to a workspace), and
2. no journey.yaml exists upstream yet.

The gate is split between the TUI (knows it's linked) and the CLI (does the check + push):

• TUI (tui/internal/services/growth/engine.go): extracted analyse-journey arg building into journeyArgs(), which appends --auto-publish only when linked (skene provider + upstream URL + key). The flag's presence marks a TUI-initiated, linked run.
• CLI (src/skene/cli/commands/analyse_journey.py): hidden --auto-publish flag + _maybe_auto_publish, gated on skene provider + linked workspace + definitive remote absence. Already-present or indeterminate results skip silently; a publish failure never fails analysis.
• Presence check (src/skene/growth_loops/upstream.py): journey_exists_upstream() calls GET /api/v1/journey/status; returns None on any indeterminate result (non-200, network error, endpoint not deployed) so callers can skip safely.
• Refactor (src/skene/growth_loops/push.py): extracted publish_bundle() so the existing push command and the new auto-publish path build an identical manifest (no behavior change to skene push).

Design decisions

• Indeterminate check -> skip silently. Only a definitive "absent" triggers a push; we never push when the check can't be completed.
• TUI-initiated only. Direct skene analyse-journey CLI runs never auto-publish, even when linked — it's gated on the flag the TUI sets.

Dependency

Needs the dashboard endpoint GET /api/v1/journey/status (SkeneTechnologies/skene-dashboard#200). Until that's deployed the presence check is indeterminate and auto-publish is a no-op, so this can merge/ship independently.

Test Plan

Automated (run locally):

• uv run pytest (395 passed, incl. the new test_upstream.py + test_analyse_journey_auto_publish.py)
• uv run ruff check clean.
• cd tui && go test ./internal/services/growth/

What the unit tests cover:

• journey_exists_upstream — 200 exists true/false; non-200 and exceptions → None (indeterminate).
• _maybe_auto_publish — full gating matrix: disabled, non-skene provider, missing upstream/token, already-present,
  indeterminate, absent→publish; plus publish-failure-never-raises.
• journeyArgs — appends --auto-publish only when provider=skene + upstream + key; omitted otherwise.

Manual end-to-end

• Deploy GET /api/v1/journey/status; curl -H "X-API-Key: " …/api/v1/journey/status → { "data": { "exists": false } } on a fresh workspace.
• Link the TUI (skene provider) and run journey analysis → expect a "Published journey to Skene Cloud" line; re-check returns exists: true and the skene.ai canvas renders.
• Re-run on the same workspace → check returns true → no re-push.
• Non-skene provider → no --auto-publish, no upstream call.
• Endpoint unreachable → publish skipped silently, analysis still succeeds.

Checklist

• PR is focused on a single change (no unrelated refactoring or cleanup)
• Tests added or updated for any behavioral change
• Documentation updated (if behavior, flags, config, or APIs changed)
• Cursor plugin updated (if commands, skills, or core CLI behavior changed) n/a
• Linting and tests pass locally
• No merge conflicts

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 32c5d9aa36

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Publish the generated journey file, not config output dir

When TUI users have a custom output_dir, runUVX exports that value as SKENE_OUTPUT_DIR, but journeyArgs() still writes the generated journey to e.bundleOutputDir()/journey.yaml. This call then lets publish_bundle() collect files from config.output_dir, so the auto-publish can upload the wrong directory (or an empty payload) and report success while the freshly generated journey.yaml never reaches Skene Cloud. Pass the actual journey output path/directory through, or make the TUI and publisher use the same directory.

Useful? React with 👍 / 👎.