Skip to content

[codex] Shift video publishing to a Post Bridge-first flow#244

Draft
FujiwaraChoki wants to merge 1 commit into
mainfrom
codex/postbridge-first-publishing
Draft

[codex] Shift video publishing to a Post Bridge-first flow#244
FujiwaraChoki wants to merge 1 commit into
mainfrom
codex/postbridge-first-publishing

Conversation

@FujiwaraChoki
Copy link
Copy Markdown
Owner

What changed

  • moved the primary video publishing flow from legacy browser-driven YouTube upload to a Post Bridge-first workflow
  • added config-backed video publishing settings, a setup wizard, publish history retrieval, and publish cron mode
  • updated the Post Bridge client, docs, setup/preflight scripts, and regression tests to match the new flow
  • kept legacy YouTube upload behavior as a deferred path by lazily initializing the browser only when that code path is used

Why it changed

The current product direction treats Post Bridge as the main publishing backend, but the CLI, config defaults, cron path, and docs were still centered on the older YouTube-first flow. This PR aligns the app with the new publishing model while preserving the existing local video-generation pipeline.

Impact

  • users can configure publishing from the CLI without editing config.json manually
  • scheduled publishing now uses publish mode instead of youtube
  • Post Bridge becomes the default backend for publishing generated videos
  • legacy YouTube browser automation remains available only where it is still needed

Root cause

The repository had partial Post Bridge integration, but the surrounding entrypoints and defaults still assumed successful YouTube upload came first and cross-posting happened afterward.

Validation

  • venv/bin/python -m unittest discover -s tests -p 'test_config.py'
  • venv/bin/python -m unittest discover -s tests -p 'test_cron_post_bridge.py'
  • venv/bin/python -m unittest discover -s tests -p 'test_post_bridge_client.py'
  • venv/bin/python -m unittest discover -s tests -p 'test_post_bridge_integration.py'
  • git diff --check

Known gaps

  • live end-to-end publishing was not exercised against a real Post Bridge account in this environment
  • venv/bin/python scripts/preflight_local.py still reports a local config blocker because nanobanana2_api_key / GEMINI_API_KEY is unset

The CLI, config, cron path, and docs now treat Post Bridge as the primary
publishing backend while retaining the local video-generation pipeline.
Legacy YouTube automation remains available only as a deferred browser path,
with browser startup moved to lazy initialization.

This also adds a config-backed setup wizard, publish history retrieval,
and test coverage for the new publishing behavior so the migration is
usable without manual config editing.

Constraint: Preserve existing local video generation while replacing the default publish path
Constraint: Keep legacy YouTube callers and tests from breaking during the transition
Rejected: Remove the YouTube class entirely | generation still depends on its existing pipeline
Rejected: Keep cron on youtube mode and cross-post afterward | conflicts with the new primary publishing model
Confidence: medium
Scope-risk: broad
Reversibility: messy
Directive: Do not reintroduce eager Firefox initialization unless the publish flow moves back to browser automation
Tested: venv/bin/python -m unittest discover -s tests -p 'test_config.py'
Tested: venv/bin/python -m unittest discover -s tests -p 'test_cron_post_bridge.py'
Tested: venv/bin/python -m unittest discover -s tests -p 'test_post_bridge_client.py'
Tested: venv/bin/python -m unittest discover -s tests -p 'test_post_bridge_integration.py'
Tested: git diff --check
Not-tested: End-to-end interactive publish flow against live Post Bridge credentials
Not-tested: scripts/preflight_local.py passes only partially in this environment because nanobanana2_api_key/GEMINI_API_KEY is unset
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant