wiki-vault/Sources/Dev/content-hub-phase6.md

created	path	project	tags	type
2026-05-31	Sources/Dev	content-hub-phase6	pbs n8n trello instagram automation flask mysql	project-plan

PBS Content Hub Phase 6 — Trello Sync & Workflow Bridge

Goal

Close the workflow gap between Jenny's existing tools (Trello, Canva, Instagram) and the Content Hub built in Phase 5.

The Phase 5 architecture assumed Jenny would create Stage 1 project records directly in the hub. She doesn't. Her planning lives in Trello, video work in Canva, posting in Instagram natively. Without Stage 1 records, the auto-match routine has nothing to match against, every published post falls into Needs Review, and the alert stream loses signal.

Phase 6 makes the hub a bridge between Jenny's existing tools and the automation — not a destination she has to adopt. Specifically:

1. Sync Jenny's Trello cards into hub projects so Stage 1 records exist by virtue of her existing planning.
2. Handle non-recipe posts (book promos, lifestyle) deterministically via a no-reply project type, eliminating false alerts.
3. Make the chat alert actionable: deep-link directly to the platform post detail page where the matching action can happen.
4. Bring the matching action to the platform post page itself, since that's the natural landing surface from an alert.
5. Add visual post recognition (thumbnails + LLM-generated fallback titles) so posts can be identified at a glance.

Locked Decisions

Decision 1: Trello → Hub Project Sync (One-Way Initially)

n8n watches Jenny's content Trello board. When a card is created or moves into specific lists, n8n creates or updates a corresponding hub Project via the existing API.

• Source of truth: Trello for project existence, title, status; hub for technical bindings (recipe link, platform post link).
• Field mapping (initial):
  • Trello card title → Project title
  • Trello list → Project status (e.g. Planned → raw, Posted → match candidate)
  • Trello label or custom field → Project type (reel, recipe-video, shop-vlog, tip, no-reply)
  • Trello card ID stored on Project for round-trip identification
• Direction: Trello → hub one-way for v1. Round-trip (hub status → Trello list) deferred until one-way is stable.

Decision 2: no-reply Project Type

Add no-reply to the existing project type list. Projects of this type are explicitly non-actionable for the comment automation:

• When a platform post is linked to a no-reply project, the comment workflow never attempts a recipe lookup.
• No alert fires on comments to no-reply posts, regardless of keyword.
• Jenny tags book promos, lifestyle posts, announcements as no-reply in Trello via label or designated list.

Makes the non-recipe case explicit instead of inferred, with zero guessing on the workflow side.

Decision 3: Alert as Google Chat Card with Deep Link

Replace the plain-text "Did not find a record!" message with a Chat Card containing:

• Platform badge (instagram / tiktok)
• Post thumbnail (fetched via Graph API)
• Post title (manual > LLM-generated > first caption sentence)
• Comment text + commenter handle
• Action button "Open in pbs-hub" → links to /admin/platform-posts/{platform_post_id}

Eliminates "copy ID from chat, switch tab, search by ID" entirely.

Decision 4: Matching Action on the Platform Post Page

The platform post detail page gains a Link-to-Project action when no project is linked:

• Project picker (searchable dropdown over existing projects, fed by Trello sync)
• Inline "Create new project" option (rare, since Trello should populate most cases)
• Quick "Mark no-reply" action that creates and links a no-reply project in one step

Once linked, the page shows the linked project with an Unlink option as it does today.

Decision 5: Visual Post Recognition

• Show the post thumbnail on the platform post detail page and in the platform posts list (fetched live from Graph API on page load; not stored).
• Title precedence: manual title > LLM-generated > first caption sentence.
• LLM title via a small Claude API call ("title this post in 3–5 words from its caption"), called once at post ingest and stored.
• Manual override always wins. LLM is the fallback that gives no-reply posts and unmapped posts a readable handle.

Decision 6: Route by External ID

Change /admin/platform-posts/{internal_id} to /admin/platform-posts/{platform_post_id} so chat alerts can construct deep links from webhook data without a lookup query. Cleaner, more shareable, and the route the chat card targets.

Decision 7: Hold-and-Flush for Held Comments

Verify or implement the Phase 4 "Queue and Retry Pattern (Option B)": comments on unmatched posts that pass the keyword gate are held in a pending_comments table with a TTL (default 24h). When the post gets matched (via Trello sync, auto-match, or manual action), held comments flush and the DM goes out. After TTL, they expire silently — no DM, no noise.

Open Items

• Which Trello board is the content board? Shared, or Jenny-only?
• What signals project type in Trello: labels, lists, or a custom field?
• Trigger for Trello → hub sync: webhook, polling, or n8n Trello node?
• LLM title generation: at ingest, or lazy on first view?
• Hold-and-flush TTL — is 24h the right default?
• Round-trip Trello sync (hub status → Trello list): include or defer?

Build Phases

Target workflow after Phase 6

Jenny creates Trello card "Vegan Pimento Cheese reel"
    ↓
n8n syncs → Project record created in hub (status: raw, type: reel)
    ↓
Jenny links recipe to project (or via Trello custom field eventually)
    ↓
Jenny posts to Instagram natively
    ↓
IG webhook → n8n writes platform_posts → pings hub /api/match/run
    ↓
Hub auto-matches by recipe.post_id or keyword
    → Match → status: live-matched, automation active
    → No match → status: needs-review, chat card sent with deep link
    ↓
Travis taps card → lands on /admin/platform-posts/{id}
    → Picks the right project from the dropdown → done
    → Or marks as no-reply if it's a book promo → done, never alerts again

Implementation steps

1. Survey Jenny's current Trello board — columns, labels, card patterns.
2. Define Trello ↔ Project field mapping with Jenny.
3. Build n8n Trello → hub sync workflow (one-way, additive, idempotent).
4. Add no-reply to project types (DB + UI).
5. Refactor platform post URL routing to use platform_post_id.
6. Replace plain-text alert with Google Chat card + deep-link button.
7. Add Link-to-Project action on platform post detail (picker + create-new + mark-no-reply).
8. Add thumbnail + LLM title to platform post ingest + detail page.
9. Verify or implement hold-and-flush with TTL.
10. Test end-to-end on staging: Trello card → publish → match → comment → DM.

Notes

Scope boundaries — not in Phase 6

• Round-trip Trello sync (hub → Trello). Deferred until one-way is stable.
• Caption authoring or scheduling from the hub. Jenny continues posting natively.
• Cross-platform parity (TikTok/YouTube). Phase 6 keeps Instagram as the primary path; other platforms inherit the bridge model but their detection workflows are separate efforts.
• Embedding pipeline / vector search (separate pbs-hub-vector-search project, deferred).

Context from prior phases

Phase 5 designed and largely built the Content Hub around a project-centric data model: Projects link to Recipes (from WordPress) and to Platform Posts (from Instagram, TikTok). The auto-match routine, two-stage lifecycle, and "Needs Review" status are already designed there. Phase 6 builds on top — it does not replace any Phase 5 decisions.

Related: content-hub-phase5-architecture, content-hub-phase5-planning, instagram-reel-sync-phase4, instagram-automation-content-hub-plan.

Key insight underlying this phase

The original Phase 5 plan made a single structural assumption that quietly broke the workflow in practice: Jenny would create Stage 1 records directly in the hub. Recognizing she doesn't — that her planning lives in Trello — reframes the hub from "a tool Jenny adopts" to "a bridge between her tools and the automation." Phase 6 is the consequence of seeing that.