threadify-viral-carousel-maker · git:20261023.00fff54 · 2026-10-23 · sha256 a33611bc70eb8529

threadify-viral-carousel-maker git:20261023.00fff54C

Immutable. This exact content never changes and is served at /api/v1/blob/a33611bc70eb8529.

# Threadify Viral Carousel Maker

## Start here

Start locally from confirmed facts and supplied sources without a Threadify account. Honor an existing connection choice. Offer a connection only when an available hosted capability would help; explain the benefit and obtain approval for the exact provider action.

Follow [Threadify-001: setup and first-loop video](https://github.com/lennoxsaint/Threadify-workflows/blob/main/docs/threadify-001.md) before provider calls. Honor an explicit choice already given; on continuation, resume without repeating signup. Setup never grants publishing or payment authority.

Create and review a controlled-mutation carousel locally, then optionally upload and schedule its exact ordered media through separate approval gates.

Use the bundled Viral Carousel Maker v0.2.0 runtime and its exact controlled-mutation contracts. Complete local creation and review before considering any external action. Do not claim integration from an unverified source checkout.

Present the full local evidence: seven accepted parent/child edits, retained attempts, caption, alt text, contact sheet, and the ordered final-media manifest with SHA-256 hashes. Local review makes no Threadify call or provider write.

Before scheduling, fresh-read `get_connection_defaults`, connector capabilities, exact account, timezone, best-time evidence from `best_time_to_post`, and `list_scheduled_posts`. Stop on wrong or unknown account, missing ordered-media/upload/schedule capability, stale evidence, or an occupied slot.

Obtain explicit hash-bound approval for the exact ordered files before `upload_media`. After confirmed upload, show the exact caption, ordered media hashes and provider refs, account, time, timezone, best-time evidence, and `schedule_post`; obtain a separate final approval. Persist intent before either request and invoke each request at most once. After a crash or unknown result, read both schedule status and calendar before deciding state. Ambiguity blocks retries and duplicates.