Skip to content

chore(conductor): add dev run script, preview URL, and safe defaults - #127

Open
plantsandchairs wants to merge 5 commits into
brightbeanxyz:mainfrom
plantsandchairs:kimi/2026-07-16-conductor-config
Open

chore(conductor): add dev run script, preview URL, and safe defaults#127
plantsandchairs wants to merge 5 commits into
brightbeanxyz:mainfrom
plantsandchairs:kimi/2026-07-16-conductor-config

Conversation

@plantsandchairs

Copy link
Copy Markdown

What\nAdds .conductor/settings.local.toml with real setup, auto_run_after_setup=false, Django dev server run script, preview URL, and budget prompt.\n\n## Why\nBrightBean was one of the repos with a bare Conductor config. This prevents accidental auto-runs and gives Conductor a real dev command.\n\n## Testing\n- [x] File syntax validated (TOML)\n- [x] No secrets leaked\n- [ ] Mercury review

plantsandchairs and others added 4 commits July 14, 2026 22:05
The existing PnC Meta app is configured through the Instagram API /
Instagram Business use case, not a separate Facebook Login app. Meta
credential resolution now falls back to PLATFORM_INSTAGRAM_APP_ID/SECRET
when the Facebook-named vars aren't set, so the existing app works
without a destructive secret rotation. Already deployed and health-checked
live prior to this commit; adding fly.toml so the deploy config is
version-controlled.

Co-Authored-By: Claude <claude-sonnet-5> <noreply@anthropic.com>
Meta renamed Instagram Graph API permissions with an "instagram_business_"
prefix (instagram_basic -> instagram_business_basic, etc.) as part of the
Instagram/Facebook Login platform unification. The old names are now
rejected outright ("Invalid Scopes") during the OAuth consent screen.
instagram_login.py already used the current names; instagram.py (the
provider actually reachable via this app's Facebook Login for Business
product) still had the old ones. Brought it in line.

Co-Authored-By: Claude <claude-sonnet-5> <noreply@anthropic.com>
- Add .conductor/settings.local.toml with real setup, auto_run_after_setup=false,
  Django dev server run script, preview URL, and budget prompt.
@plantsandchairs
plantsandchairs requested a review from JanSchm as a code owner July 16, 2026 14:11

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 20a6929a04

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread config/settings/base.py
Comment on lines +365 to +367
"app_id": env("PLATFORM_FACEBOOK_APP_ID", default="") or env("PLATFORM_INSTAGRAM_APP_ID", default=""),
"app_secret": env("PLATFORM_FACEBOOK_APP_SECRET", default="")
or env("PLATFORM_INSTAGRAM_APP_SECRET", default=""),

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Keep Instagram Login creds out of Meta OAuth

When a deployment follows the documented Instagram (Direct) setup and sets only PLATFORM_INSTAGRAM_APP_ID/PLATFORM_INSTAGRAM_APP_SECRET, this fallback also makes the shared _META_CREDENTIALS complete for facebook, instagram, and threads because PLATFORM_CREDENTIALS_FROM_ENV maps all three to this dict. Those connectors then appear configured and their Facebook/Threads/Graph OAuth flows use the Instagram Login App ID/secret, which the README documents as different from the Facebook App ID/secret, so direct-only deployments get broken connect options instead of leaving those platforms unconfigured.

Useful? React with 👍 / 👎.

Comment thread fly.toml
auto_stop_machines = true
auto_start_machines = true
min_machines_running = 0
processes = ['app']

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Add a Fly worker process for background tasks

For deployments using this new fly.toml, only the default app process is started, so the image runs the Dockerfile Gunicorn CMD but never starts python manage.py process_tasks like Procfile:3 and the production compose worker do. The scheduled publisher, inbox sync, notification retries, and other recurring jobs in this repo are registered for django-background-tasks, so on Fly scheduled posts and background maintenance will not run unless a worker process group is defined and scaled alongside the web process.

Useful? React with 👍 / 👎.

Housekeeping snapshot of uncommitted work so the tree is clean and everything is
tracked. Content is whatever each agent/session left in progress; this commit
changes no behaviour and makes no judgement about the work itself.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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