JITRBeats

An automated music marketing system — a business-in-a-box for digital content operations.

Last updated Apr 20, 2026 · 22 features · 137 roadmap items

Features What JITRBeats does today — 22 capabilities across 5 areas

Posting Machine

Auto-posting across five platforms
New
Clips post to Facebook Reels, Instagram Reels, YouTube Shorts, TikTok, and X/Twitter on an automated schedule. Each platform has its own poster tuned to how that platform actually works: Facebook and Instagram share caption and timing logic, YouTube enforces a stricter cadence (base 4 hours with ±25% variability and a 24-hour no-repeat rule), and X is triggered automatically after every successful YouTube upload so the release gets announced with the Shorts link. All five draw from the same central clip selector — posting priorities set once propagate everywhere.
RecentlyFrequency-control denominator bug fixed — was hardcoded 24, now computes effe…  ·  Skip / FrequencyPass log lines now emit denom= field for observability  ·  Config doc updated with corrected probability examples; old doc described bug…
Human-feeling post variety
New
Each post's caption is drawn from a two-tier pool: branded lyric lines for song-specific clips (weighted 30%) and a 161-line commentary pool for the rest. Hashtag counts are probabilistic — zero to fifteen tags per post, drawn from core / clip-type / genre / discovery pools — so no two posts have the same shape. Timing jitters zero to forty-five minutes off the schedule to avoid clock-boundary patterns that flag as spam. Configurable quiet hours skip overnight posts. YouTube rotates between two title formats so the same song never appears back-to-back in the identical phrasing. The feed is believable because it isn't uniform — a reader sees the variety a human would have created.
RecentlyFrequency-control denominator bug fixed — was hardcoded 24, now computes effe…  ·  Skip / FrequencyPass log lines now emit denom= field for observability  ·  Config doc updated with corrected probability examples; old doc described bug…
Slot-filling supply management
New
Each platform maintains a rolling buffer of pre-selected, pre-scored clips so the posters never stall waiting for content selection. When a clip is consumed, a refiller picks the next one via the central selector and stages it into the supply folder, ready for the next post. Supply folders live on Google Drive for mobile access, with defensive checksum verification guarding against partial moves. A slot is never emptied unless its replacement is already in place.
TikTok manual-post queue
New
Until TikTok's Content Posting API is approved for automated publishing, JITRBeats still drives TikTok end-to-end. Six clips are staged in Google Drive slots every day using the same selector and scoring logic that drives every other platform. A human posts them with a tap from the TikTok mobile app — the selection, timing, and caption context are identical to what the automated poster will do the moment approval lands.
Platform token refresh
Meta access tokens (which expire roughly every sixty days) and Dropbox access tokens refresh themselves automatically. Meta refresh exchanges a short-lived user token for a long-lived one, derives the Page and Instagram Business credentials from Meta's APIs, and atomically swaps the old credentials only after the new ones have been validated live. Dropbox refresh pulls a fresh access token using the stored long-term refresh token. All credentials live in macOS Keychain, never in log files or environment echoes. The posting machine never stops because a credential silently expired.
Posting integrity reporting
New
Every platform has a daily reporter that reads the poster's own log and turns the day into numbers: how many posts went out, how many failed, whether any errors appeared, and for YouTube whether the AI-content-ratio target (under 20% of posts tagged AI) is holding. Reports compare observed posting against configured targets — twelve per day for Facebook and Instagram, five-plus for YouTube — and color-code GREEN, YELLOW, or RED with explicit intervention flags so Jeff knows at a glance when to look versus when everything is fine. ---
RecentlyAdded IG failure detection — IG_PROCESS_FAILED, IG_POLL_TIMEOUT, IG_PUBLISH_F…  ·  Failures now shown as separate category with RED/GREEN status, detail table w…  ·  Canonical log format aligned — poster now emits 5 distinct event types

Creatives Library

Canonical clip naming
New
Every clip in the library carries a deterministic filename encoding three pieces of meaning: the pool it belongs to (general, song-specific, or Pronounce Hecojeni), a twelve-character content hash that stays with the file for life, and the clip's current effectiveness score as a four-digit suffix (5000 is neutral, scores drift up on engagement and down with age). The hash never changes — it is the file's identity. The score changes constantly: a nightly pass reads the scoring events queue, applies the percentage-delta math, and renames files to reflect the new score. This two-part naming is the spine of the whole system — every downstream program, from selector to poster to scorer to reporter, reads meaning directly from the filename, so a clip's rank, provenance, and history are always recoverable without a database.
Age-aware clip rotation
New
The library reacts to a clip's age as an enduring capability. At thirty days old, a clip picks up a +30% score boost on the theory it has had time to find its audience. At one year old, it takes a -10% decay to quietly yield rotation to fresher material. The system detects these milestones with a stateless time-window pass — each clip's birthday event fires exactly once, missed runs automatically catch themselves up, and no per-file ledger is needed. Evergreen clips stay evergreen, aging clips phase down on their own, and the library never calcifies around a handful of perennial posts.
Engagement-based re-ranking
New
Every post's real-world performance feeds back into what gets posted next. Three platform scorers — Facebook, Instagram, YouTube — fetch each posted clip's live likes and comments and compare them to the account's own 30-day rolling average. A post that hit 2x its recent average picks up a score boost; a post at half-average takes a small hit. The model is ratio-based, not fixed-threshold, so "good performer" is defined by your own recent history, not an absolute number. A separate pool-level recommender aggregates these signals across each content pool on a 30-day half-life and suggests updated posting-mix weights — pools whose clips are actually winning get more airtime, pools that are quiet get less. Weight suggestions are advisory: the human stays in the loop on what to adopt.
Queue-backed weighted pool selection
New
Nothing in JITRBeats picks a clip at random on demand. When a poster needs its next video, it pulls from a pre-filled queue that a separate process stocks in batches honoring the active pool weights. If a new release is configured for 30% of airtime for the next four weeks, one line changes in the weights config and the next queue fill reflects it — every poster, every platform, one source of truth. This queue-backed design eliminates surprise skew, makes the posting mix auditable (a daily ledger audit compares actual picks against configured weights and flags drift), and lets weight changes take effect deterministically rather than after some uncertain number of random samples.
Library hygiene
New
Four passes keep the 4,600-clip library structurally sound without human oversight. A deduper computes a true content hash (SHA-256) on every file and quarantines exact duplicates — rename-fooled duplicates do not slip through. A durationer splits any clip longer than thirty seconds into TikTok-and-Instagram-native chunks that inherit the parent's canonical naming. The canonical-naming enforcer catches any file that drifted out of spec during production or Dropbox sync. A daily compliance report flags the percentage of the library that is out of format, so structural drift is visible before it becomes a problem. Old logs and reports are trimmed to ninety days so the system's own exhaust does not grow forever. ---

Spotlight — Production Flow

Song production flow
Tracks whether music production is moving work through or building backlog at any given stage. Two daily signals drive the assessment: a Mix Backlog metric (the ratio of archived old mixes to current work — green when older takes are clearing as fast as new work arrives, red when the backlog accumulates), and a Premaster Readiness metric (premaster WAVs per active project — green when projects are flowing smoothly toward mastering, red when work queues upstream). A separate daily song-journey ledger captures each song's milestone dates from old mix through final master, so stage-to-stage lead times are there to be analyzed when the bottleneck investigation matters. The system is evolving — semantics of "active project" and the right way to weight lead-time versus inventory are still being refined — but the enduring capability is flow-first visibility into the music side of the machine.
Video pipeline runway
Answers three operational questions about clip supply and consumption, every hour. Inventory Runway: how many days of max-posting (42 per day) the ready-to-post clip folder can sustain before running dry — green at 45+ days, red below 20. Pipeline Runway: how many days of future posting capacity the raw-footage feeder can generate once cut down to clips — green at 90+ days, red below 30. Conversion Ratio: whether raw-to-clip editing velocity is outpacing consumption — green means the pipeline is building a buffer, red means we are consuming clips faster than they can be produced. Together, these three numbers detect content-starvation risk before it becomes a missed-post day: low inventory + low pipeline means an imminent stall; a high conversion ratio flags an editing bottleneck upstream. ---

Operator Visibility

Live ops dashboard
New
A single-screen operator view of the machine right now: posting counts against daily and seven-day targets per platform, engagement scoring activity, and any reporter or system issue that needs attention. Mobile-first HTML with a rich link-preview card when the URL is shared, one tap from the iPhone home screen, regenerated and redeployed to Cloudflare every two hours. Replaces hand-scanning per-subsystem log files. No JavaScript, no external assets — renders identically on any browser.
Artist dashboard
New
The same underlying data as the ops dashboard, articulated for the artist. Leads with engagement standouts (top-performing posts with direct tap-through links to the live Instagram or Facebook URL), posting totals for the last 24 hours and the last 7 days, and a one-line plain-English summary. Drops the operational noise — no reporter-staleness alerts, no token warnings, no WIP labels. Distinct orange-to-purple gradient so it feels different at a glance from the ops view.
Daily email push
New
Short plain-text emails that land in the inbox twice a day (6 AM and 4 PM for operations; morning-only for the artist audience) with a rich link-preview card that fetches the hosted dashboard's OpenGraph tags. The email is the push; the page is the content. Replaces a 42 KB text-dump legacy email with a few lines plus a tappable link that opens the full current dashboard. Routing is separate per audience — operator mail to the JITR inbox, artist mail to Hecojeni and his manager on the morning run only.
Product and roadmap site
New
A public, always-current feature list and forward roadmap for JITRBeats as a product. Features are hand-curated in a manifest file that groups underlying programs into business-facing capabilities; roadmap is auto-extracted from the per-program roadmap files in the codebase, with completed items self-filtering via DONE-date markers. Each tile shows a "Recently" line auto-populated from the most recent DONE dates in that program's roadmap and a small "New" badge if any underlying program was touched in the last thirty days. The source-of-truth files — the manifest and the roadmap Markdown — are edited like any other code artifact.
Legacy daily snapshot email
A per-subsystem text-only email that aggregates whatever reporter outputs are currently in the DailyEmail folder and mails them as a single snapshot. Still running while the graphical dashboards absorb its coverage. Scheduled for retirement after the dashboards have replaced its function in daily use — maintained until the sunset decision, not being extended. ---

Business Operations

JITR internal expense generation
New
JITRBeats does its own accounting on the operator side, too. A monthly pass over the JITR-owned filesystem estimates labor hours spent across IT, sound, video editing, artist support, and marketing — using file-modification patterns with sessionization rules (gaps of 20 minutes or less count as the same session, runs under 2 minutes are ignored) and fixed hourly rates per category (IT: $200/hr, Video: $50/hr, Sound: $75/hr). Output is a canonical CSV ledger under the Business Files tree plus a detailed evidence report showing hours by category. Automated CSV ledgers are the chosen design — no Zoho, no third-party bookkeeping platform — so every line has a direct provenance back to filesystem evidence and the books are auditable without importing proprietary data.
Monthly client billing (in development)
Consumes the monthly expense and activity data and constructs itemized service charges for the client under JITR's rule set — video management, cloud storage, email campaigns, newsletter, Patreon administration, release packages. Outcome-based rules (for example: clip counts under 100 are free; above 100, the greater of $500 or $0.50 per clip; storage at $0.25 per gigabyte). JITR is the single billing face to the client; contractors and vendors bill JITR, and JITR re-bills the client as a pass-through line on a single invoice with no default markup. Currently in DEV; moves to PROD once the test cycle validates every rule against historical data.
Historical billing reconstruction (in development)
New
Reconstructs month-by-month client charges retroactively from April 2022 onward using the current rule set and filesystem evidence. Useful for reconciliation, audit trails, and catching cases where historical billing differs from what the current rules would produce. Reads the same monthly activity data as the live billing pipeline and outputs month-by-month reports. Currently in DEV.
Monthly narrative builder (in development)
Produces a human-readable narrative — plain text and Word — that chronicles what the artist created in a given month, organized by song project and media type (audio, video, images, documents). Suitable for artist review, fan-facing monthly updates, or management context. Currently in DEV; the artist-facing framing is under refinement ahead of PROD promotion.
Roadmap Approved business functionality, direction not commitment — 137 items
AgeScorer
Configurable thresholds
New
- Make 30-day (boost) and 365-day (decay) thresholds configurable rather than hardcoded - Business value: Allows tuning content lifecycle strategy without code changes as posting patterns evolve
Audio normalizer
Audio normalizer
New
# Audio_normalizer Roadmap Program: Audio_normalizer Roadmap: none
Audio Splitter
Audio Splitter
New
Program: Audio_Splitter Roadmap: 1) Execute full release management process for initial production deployment - Establish known state across dev/prod/emer - Create dev README with scope and test evidence - Capture dev vs prod diff (new program baseline)
Billing
AI VIDEO PRODUCTION
New
### Pricing Rule - $3 per clip - 100 clip minimum per song ### What Counts - Files where path contains: - TikTok and Reel Clips - Song Specific - AI
Billing
ARCHITECTURAL PRINCIPLE
New
Billing MUST: - Count files - Apply rules Billing MUST NOT: - Deduplicate - Clean data - Infer history ---
Billing
AUDIO PRODUCTION
New
### Pricing Rule (CONFIRMED / REVISED 2026-04-09) - Producer support: - track one 1/2-day producer block for every detected recording session - track one 1/2-day producer block for every detected mix session - bill at $0.00 during recording / mixing - Studio time: - recording sessions only - $50/hour
Billing
PURPOSE
New
Generate a complete, accurate, repeatable monthly bill. NO interpretation. NO re-decisions. Filesystem + rules only. --- # 🔒 LOCKED BILLING MODEL (AUTHORITATIVE)
Billing
STEP 0 — DUMP CURRENT RULES
New
Output ALL current billing rules: - taxonomy - rate card - any hard-coded logic Goal: "this is what we have decided" ---
Billing
STEP 1 — LOAD COLLECTOR DATA
New
Input: - Collector CSV (~20k rows) ---
Billing
STEP 2 — COVERAGE CHECK
New
For every row: - Does a billing rule classify it? Output: - UNCLASSIFIED rows ---
Billing
STEP 3 — DEFINE NEW RULES
New
For each uncovered pattern: - Create rule - Define: - activity - billing method - evidence mapping ---
Billing
STEP 4 — PERSIST RULES
New
Write to: - taxonomy - rate card - roadmap (if needed) NO TEMP LOGIC NO INLINE HACKS ---
Billing
STEP 5 — RE-RUN COVERAGE
New
Repeat until: - 100% classification --- # 🚀 EXECUTION PHASE (ONLY AFTER COVERAGE = 100%) 1. Run billing builder 2. Generate charges 3. Generate evidence mapping 4. Manual hard costs (Jeff)
Billing
STORAGE
New
### Pricing Rule (CONFIRMED 2026-04-09) - $0.50 per GB per month ### What Counts - All files under ARTIST_ROOT excluding the entire Videos folder when clips >= 100 - When clips < 100: excludes only TikTok and Reel Clips subfolder - Rationale: when clip management is billed (100+ clips), all video storage is already covered — only non-video files (Recording Files, Released Music, Business Files, Photos) are charged fo…
Billing
VIDEO MANAGEMENT
New
### Pricing Rule (CONFIRMED 2026-04-09) - 100 or fewer clips: no charge - 101+ clips: min($3,000, max($500, total_clips × $0.50)) ### What Counts - ALL video clips (.mp4, .mov) under: Videos/TikTok and Reel Clips/ - Includes: - all subfolders
BlankVideoSweeper
Active Work
New
- Tune blank detection thresholds (blackdetect + silencedetect) so known blank files are correctly identified (current logic too strict; confirmed via manual ffmpeg test). - Validate detection across real dataset (e.g., Summers Calling folder) to ensure no false negatives or false positives.
BlankVideoSweeper
Future (Discussed, Not Yet Implemented)
New
- Performance improvements (parallel processing to speed up scanning). - Option to skip previously scanned files to reduce runtime on repeated runs.
BlankVideoSweeper
Pending Decisions / Open Questions
New
- Whether to preserve original folder structure when moving files to quarantine.
cd order processor
cd order processor
New
PROGRAM: cd_order_processor PURPOSE End-to-end automation for CD orders placed through Stripe Checkout for Hecojeni's Radio Promo CDs. When a customer completes payment, this program tags the customer in AWeber, submits a manufacture+ship order to Kunaki, notifies Jeff, and logs the full transaction. Runs daily via launchd; idempotent via a local ledger so the same Stripe session is never processed twice.
cloud migration
cloud migration
New
JITRBeats Cloud Migration — Roadmap (Effort-Owned) Scope decision (Jeff, 2026-04-20): EVERYTHING moves to the cloud. No hybrid. - Implication: osascript/Apple Mail email pattern will be replaced (authorized by "everything moves"). - Implication: every macOS-specific dependency must have a cloud replacement, not an exemption.
collector
collector
New
PROGRAM: collector.py ROADMAP 1) Schedule monthly collector execution - Schedule collector to run at 12:00 am on the first of every month - Apply launchd only on the Mac mini using the JITRBeats launchd standard
deduper
deduper
DEDUPER ROADMAP 1. Add reporter (runs immediately after deduper) - Output to: $JITR_REPORTS/DailyEmail/Deduper/ - Include: videos scanned, duplicate groups, runtime, status 2. Fix ETA / avg time calculation - Current issue: avg=0s/file
durationer
durationer
New
# durationer — roadmap 1. Standardize temporary video storage location - Move working files under "Duplicate Video Working Area - Aged at 90 Days" - Per-program subfolder (durationer) - Enforce 90-day deletion on every run Goal: align with project-wide aging/temp storage standard
EngagementScoring
Priority 5: TikTok Ledger + Scorer
New
- [DONE 2026-04-14] TikTokFileMgt_multi_refiller.sh now logs a posting ledger at $JITR_STATE/TikTokFileMgt_ledger.csv (schema: ts_utc,slot_num,asset_basename,dbx_rel_path) on every successful slot fill. First ledger rows write at the next 02:00 run. - [TODO] Build TikTok API collector to retrieve recent video list with create_time.
EngagementScoring
Priority 6: Cross-Platform Engagement Reporter
New
- Build a reporter that queries across all platforms: "top 10 Instagram clips of all time", "best performers across all platforms this month", etc. - Pull from scoring queues and/or posting ledgers joined with engagement data. - Output to screen + report file, compatible with DailyEmailer.
EngagementScoring
Priority 7: Watermarking (fallback, only if needed)
New
- Only pursue if TikTok time-matching (Priority 4) proves unreliable. - Design: visible pixel watermark with lane + id_hex, high contrast, full duration. - Implementation: centralized watermark generator using FFmpeg drawtext. - Validation: post watermarked test video, retrieve, confirm readability. - Business value: platform-independent identity system. Insurance policy if any platform breaks ledger-based matching.
FacebookReels poster
Backup Retention Hygiene
New
- Before writing a new backup file, first remove stale older backups for that same artifact - Default retention target: remove backup files older than 30 days unless that specific program requires something different - Keep the live file intact; clean only prior backup clutter - Apply this deliberately in future releases so backup growth does not accumulate in config, logs, reports, tmp, or roadmap areas
FacebookReels poster
Cloud Readiness
New
- Prepare for cloud execution
FacebookReels poster
Error Notification
New
- Implement alerting for failures
FacebookReels poster
File Management / Retention Cleanup (shared concern)
New
- (PENDING: Layer into remaining scorers/reporters/splitters as they are touched in future work) - (PENDING: JITRCleaner rescheduled via launchd as safety net for shared dirs)
FacebookReels poster
Multi-Client Support
New
- Support multiple Facebook pages/accounts
FacebookReels poster
UI / Mobile
New
- Support monitoring and control via UI/mobile
Hecojeni Billing Historical Table
Priority 1 — Jeff Review Of Current DEV Billing Output
New
Business value: - Prevent newly discovered categories from becoming invoice-facing before the month-level charges pass business review. Current review anchors: - 2025-01: calculated charges are $225.52, so Client Minimum adds $274.48 to reach $500.00 - 2025-02: calculated charges are $97.33, so Client Minimum adds $402.67 to reach $500.00 - 2025-03: includes 7 recording sessions under the current song-project rule, w…
Hecojeni Billing Historical Table
Priority 2 — Deliberate DEV To PROD Release
New
Business value: - Move the validated historical table into PROD with a known rollback point, instead of trusting the older PROD copy. Notes: - Follow Jeff's release-management process for this one program only. - Prod was previously called untrusted during turnover. - No launchd work is expected unless Jeff asks for scheduling.
Hecojeni Billing Historical Table
Priority 3 — Reconcile Historical Table With JITR Billing Roadmap
New
Business value: - Avoid maintaining two competing billing systems: the practical historical table and the broader collector/rule-engine billing plan. Reference: - scripts/roadmap/JITR_Billing_roadmap.md
Hecojeni Billing Historical Table
Priority 4 — Invoice-Ready Evidence Mapping
New
Business value: - Let Jeff inspect exactly which filesystem / collector / receipt evidence caused each monthly charge before creating a customer invoice. Known evidence sources already in use: - Brevo monthly receipt CSV for email counts - Monthly Updates folder filename evidence for newsletter / Patreon - Collector CSV plus current MP3 duration check for audio recording / mixing - Filesystem snapshot logic for video…
Hecojeni Billing Historical Table
Purpose
New
Track remaining work for the DEV/PROD historical billing table. Completed release-specific work belongs in scripts/dev/Hecojeni_Billing_Historical_Table.readme.md.
Internal JITR Expense Generator
Accounting Roadmap Notes Added 2026-04-11
New
These notes preserve the current accounting-only direction after the 2025 JITR / SWS / Hecojeni review work. They are roadmap inputs, not a directive to code every item before the next release. ### A. Freeze Business Formulae Lock the current business rules before pushing numbers into Zoho or backfilling history.
Internal JITR Expense Generator
Annual Close and Tax Support
New
Generate annual outputs including: - totals - summaries - tax-support files Support full year-end accounting. ---
Internal JITR Expense Generator
Completed (moved to dev release notes)
New
- Canonical Home - System Boundary - Filesystem Cleanup ---
Internal JITR Expense Generator
Cross-System Roadmap Notes Added 2026-04-10
New
These notes are roadmap inputs for the broader accounting system. They are not a directive that they must be implemented immediately before all other work. ### A. Collector Gap Assessment Original design intent was: - collector runs once per month - collector emits one monthly activity CSV - downstream systems consume that shared monthly evidence Observed reality is: - the current collector is still valuable, but it…
Internal JITR Expense Generator
Determine JITR Month Zero
New
Identify the earliest defensible month of JITR activity. This may include work outside Hecojeni. Define this as the starting point for all historical accounting. ---
Internal JITR Expense Generator
End State
New
A complete internal accounting system that: - covers all months since inception - produces monthly, quarterly, and annual outputs - supports tax reporting - cleanly separates internal vs pass-through costs
Internal JITR Expense Generator
Hard-Cost Classification
New
Each cost must be classified as: - Internal JITR expense - Pass-through (receivable) - Non-JITR / excluded This classification must be explicit and consistent. ---
Internal JITR Expense Generator
Hard-Cost Intake Process
New
Define a repeatable process for ingesting receipts and transactions. Support mixed input types. Ensure: - receipts are stored - extracted data is machine-readable - process is repeatable and auditable ---
Internal JITR Expense Generator
Historical Backfill
New
From Month Zero to present: For each month: - generate soft-cost outputs - store results in canonical structure Cover all months since inception. ---
Internal JITR Expense Generator
Lifecycle Arc — All-Entity, All-Months, From Month Zero (Jeff direction 2026-04-20)
New
This is the long-arc destination for the entire accounting workstream. Every per-script roadmap item below ladders into one of these phases. ### Phase L1. Find Month Zero for Every Entity For every entity in scope, identify the earliest defensible month of activity.
Internal JITR Expense Generator
Monthly Accounting Outputs
New
For each month, produce: - soft-cost outputs - hard-cost outputs - pass-through entries - accounting support files These must be complete enough to support accounting updates. ---
Internal JITR Expense Generator
Monthly Close Definition
New
A month is complete only when: - soft costs are calculated - hard costs are identified - classification is complete - Zoho files are generated - Zoho is updated ---
Internal JITR Expense Generator
Objective
New
Build the full internal accounting engine for Just in Time Records from inception through present. This system is responsible for: - internal JITR expenses - soft-cost labor accounting - hard-cost intake and classification - pass-through vs internal distinction - Zoho-ready accounting outputs - monthly close
Internal JITR Expense Generator
Quarterly Reporting
New
Generate quarterly summaries of: - internal costs - pass-through activity - trends ---
Internal JITR Expense Generator
Reintroduce Chat-Based Time Tracking
New
Recover or rebuild the method that derives work time from chat history. Integrate it with filesystem-derived time. Produce a single unified internal labor model. ---
Internal JITR Expense Generator
Soft-Cost Method (Filesystem + Chat Time)
New
Define the official canonical method for calculating internal labor costs. Canonical month-based soft-cost method: 1. Filesystem-derived activity - Use month-bounded file-touch sessionization as the current phase-1 baseline. - Current governed session rules: - gap <= 20 minutes => same session - sessions < 2 minutes ignored - Current governed categories:
Internal JITR Expense Generator
Zoho Integration
New
Generate accounting outputs in a format ready for Zoho. Eliminate manual preparation of accounting data. ---
JITRCleaner
Absorbed scope
New
The following standalone roadmap has been folded into JITRCleaner and should be retired: - Prod_Hygiene_and_Shim_Checker.txt — its items (shim hunt, prod hygiene audit, orphan launchd references, cross-machine validation, weekly consolidated report) are now priorities below. The Log_and_Report_Cleanup.md roadmap is already satisfied by Phase 0 and should also be retired. ---
JITRCleaner
Open questions (carry forward, do not code on)
New
- Should "best practices advisory" become its own lightweight document the program teams are pointed at, so they know in advance what JITRCleaner will complain about? (Jeff mentioned this framing.) - Should JITRCleaner write directly into each offending program's roadmap file, or only into the consolidated report? Writing into roadmaps is pushier but also harder to undo.
JITRCleaner
Priority 1 — Discovery pass: what is dirty?
New
Business value: before we can advise, we need a baseline inventory of what's actually out there. One read-only walk of the JITRBeats footprint, classifying findings. Scope of the walk: - scripts/dev, scripts/prod, scripts/emer, scripts/roadmap, scripts/archives - config/ and config/_archive - JITR_TMP, JITR_LOGS, JITR_REPORTS, JITR_STATE
JITRCleaner
Priority 2 — Owner attribution
New
Business value: the report is only useful if Jeff (or the next dev) can tell at a glance which program needs to fix what. A wall of findings with no owners just becomes Jeff's problem. Attribution rules: - Filename prefix match against known program names (e.g. AgeScorer_*.bak belongs to AgeScorer). - Roadmap directory scan for program names. - launchd label scan.
JITRCleaner
Priority 3 — Advisory report + email integration
New
Business value: the report needs to land somewhere Jeff actually sees it, and it needs to be actionable — a nudge to the owning program team's next dev session, not a log file nobody reads. - Write report to JITR_REPORTS/DailyEmail/JITRCleaner/ alongside the existing cleanup report. - Consolidated format: top-line counts, then per-program sections.
JITRCleaner
Priority 4 — Escalation policy for unowned messes
New
Business value: some findings will never get an owner. Without an escalation path, they sit in the report forever and the report loses credibility. Proposed policy (to be confirmed with Jeff before implementation): - First appearance in report: advisory only. - Still present after N weeks with no action: JITRCleaner sweeps it under the failsafe layer. - Always logged, never silent. ---
JITRCleaner
Priority 5 — Known hardening of existing Phase 0 code
New
Business value: the shipped failsafe layer has known-fragile spots the previous team flagged. These don't block discovery work but should be fixed before the program is considered mature. - Filename-safe iteration: for F in $(find …) breaks on spaces/newlines. Switch to null-delimited find -print0 + while IFS= read -r -d ''.
JITRCleaner
Priority 6 — Cross-machine awareness
New
Business value: JITRBeats runs across Jeff's Macs; hygiene findings on one machine aren't necessarily true on another. Per shim policy, the discovery walk must be portable and must not confuse a machine-local absence with a system-wide absence. - Report header must identify which machine produced it. - launchd discovery only meaningful on the Mac mini — flag, don't alarm, when run elsewhere. ---
JITRCleaner
Vision
New
JITRCleaner is the system-hygiene program for JITRBeats. Its job is not just to delete old files — it is to keep the whole environment clean, and to push responsibility for cleanliness back onto the program that caused the mess. Three layers, in order of preference: 1. Discovery. Find what is dirty/stale/out-of-place across the JITRBeats footprint. Attribute each finding to the owning program whenever possible. 2.
JITRDashboard
Absorb Spotlight flow model into the dashboard (PARKED 2026-04-18)
New
Business value: Elevates the dashboard from "posts today" to "is the machine flowing or clogging end-to-end?" — the real executive question. Spotlight already has working PROD scripts producing trend CSVs; this is about rendering them graphically in JITRDashboard, not rebuilding the collection.
JITRDashboard
Automate fan-count collection from platform APIs (follow-on)
New
Business value: Removes Jeff's weekly data-entry task, eliminates the staleness risk from #6, and enables daily-granularity growth tracking instead of weekly. Scope: - Facebook Page followers via Graph API — token and refresh already solved. - Instagram Business followers via Graph API — same. - YouTube subscribers + video count via YouTube Data API — API key already present.
JITRDashboard
Explicitly not on the roadmap
New
- Real-time streaming / websockets. 15-minute regeneration is plenty for this use case. - Power BI / tableau / any licensed BI tool. Wrong shape for a one-person operator dashboard. - Public fan-facing dashboard at hecojeni.com. Possible future initiative, but belongs on a different roadmap (artist site, not ops).
JITRDashboard
External dependencies (NOT owned here)
New
- TikTok engagement data (views, likes, comments, shares) — assigned to the TikTok automated poster team. They will deliver engagement output in a scorer-shaped file (same shape as Facebook/Instagram scorers). When that lands, JITRDashboard removes the WIP flag on TikTok's platform card and lights up its engagement card.
JITRDashboard
Fan-growth callout on the JITRBeats product page (investor-facing)
New
Business value: Concrete audience-growth data on the public product page is the strongest single investor / prospect signal we can surface. Abstracts the machine's effectiveness into one number. Scope: - Add a "Audience" callout near the hero on the JITRProduct page: "N followers across 5 platforms · +M over the last 12 weeks." - Source: the same Hecojeni Metrics reader built in #6.
JITRDashboard
Fork the generator into an artist (Hecojeni) view
New
Business value: Two audiences (operator vs artist) get articulations that match their interests — Jeff sees "is it working?", Hecojeni sees "how is my music doing?" — from the same underlying data. Scope: - Output path: $JITR_REPORTS/Dashboard/hecojeni/index.html - Artist view drops: stale reporter alerts, token warnings, pool-decay noise, WIP status language - Artist view emphasizes: engagement trend, standout clips…
JITRDashboard
Historical sparklines (7-day posting cadence per platform)
New
Business value: Lets Jeff see trends, not just today — catches slow slides before they become red. Scope: - Persist a daily rollup in $JITR_STATE/JITRDashboard_history.csv (one row per platform per day) - Inline SVG sparklines on each platform card (no external charting dependency) - 7-day window; monthly rollup separate
JITRDashboard
Host the ops dashboard on a subdomain (Cloudflare Pages + GoDaddy DNS)
New
Business value: Jeff's exec view becomes always-current from any device, tappable from the iPhone home screen as a PWA. Replaces "delete the daily email" friction with "glance at the dashboard." Scope: - Create a Cloudflare account (free tier) - Create a Cloudflare Pages project pointed at the dashboard output - Point a subdomain (e.g.
JITRDashboard
Ingest Hecojeni Metrics (fan growth) into the presentation layer
New
Business value: Makes the real fan-funnel numbers visible in the same place Jeff and Hecojeni are already looking. JITRBeats' North Star is 5K Patreon fans — current total is ~280 followers across five platforms. That gap is the whole point of the machine, and it belongs front-of-mind on the daily dashboards, not buried in a spreadsheet.
JITRDashboard
Monthly AI video recap (Hecojeni-facing)
New
Business value: A watchable 2-minute "here's your month" clip — the kind of thing that's actually forwardable, celebrates growth, and keeps artist engaged in the system. Scope: - Monthly cadence only (NOT daily — a daily AI newscast of "everything's fine" is worse than no newscast) - Script generated from the artist dashboard data (reach, top clips, growth) - Narration via ElevenLabs or HeyGen avatar - Delivered to H…
JITRDashboard
Push alerts layer (event-driven, separate from dashboard)
New
Business value: Jeff stops checking and the system tells him when something needs attention. Converts the dashboard from something to pull-to into something that quietly handles itself 95% of the time. Scope: - Integrate Pushover (one-time $5, iOS app with native banners) OR iMessage via AppleScript - Triggers: posting stops on any platform > 6h, token expiry within 48h, IG_PROCESS_FAILED spike, reporter staleness cr…
JITRDashboard
Real-phone testing + PWA polish
New
Business value: Dashboard lives on Jeff's iPhone home screen like a native app — one tap. Scope: - Add apple-touch-icon and manifest.webmanifest - "Add to Home Screen" produces a clean icon + full-screen app feel - Test on actual iPhone over cellular; iterate on spacing/font-size - Verify Safari vs Chrome render parity
JITRDashboard
Schedule regeneration via launchd
New
Business value: Dashboard is always fresh without Jeff thinking about it. Scope: - Mac mini only (per JITRBeats LaunchD standard) - Cadence: every 15 minutes - Wrapper .sh script that sources shim + jitr_vars.env then calls the Python generator - Once hosted, same schedule also pushes to Cloudflare Pages - Full JITRBeats LaunchD Standard: no exec, no process substitution, local OS-native paths for launchd-level logs
JITRDashboard
Slim or retire the DailyEmailer
New
Business value: Reduces noise and avoids two sources of truth once the dashboard + alerts are load-bearing. Scope: - Option A: keep a daily email but reduce it to a single mobile-friendly card + "Open dashboard →" button - Option B: retire it entirely - Decision to happen after items 1–5 are in prod and Jeff has had a week to live with dashboard + alerts
JITRDashboard
State of the Library section (both dashboards)
New
Business value: One-glance answer to "what do we actually have, and how healthy is the library?" — independent of what posted today. Surfaces anomalies that would otherwise hide in the file system forever (mis-named clips, unusual durations, score outliers).
JITRDashboard
Weekly investor-grade email cadence (PARKED 2026-04-18)
New
Business value: A separate, weekly-cadence email aimed at a different audience (Jeff-as-business-operator, future investors) covering releases this week, feature list updates, roadmap progress. Different template from daily ops/artist emails. This is the signal buried in the WeeklyReporter turnover.
MetaAutoPoster reporter
Cloud Readiness
New
- Prepare reporter for cloud-based aggregation
MetaAutoPoster reporter
Daily Email Integration
New
- Write one canonical report file per run - Output to: $JITR_REPORTS/DailyEmail/Meta/ - Filename pattern: YYYYMMDD_HHMM-MetaReport.txt - Ensure compatibility with DailyEmailer.sh ingestion model - Maintain stdout output for direct invocation
MetaAutoPoster reporter
Data Accuracy
New
- Handle mixed log formats safely
MetaAutoPoster reporter
Error Notification
New
- Integrate alerting for critical failures
MetaAutoPoster reporter
Multi-Client Support
New
- Support reporting across multiple clients/accounts
MetaAutoPoster reporter
Reporting Enhancements
New
- Improve reporting to be more insightful - Expand visibility into retries and pipeline health
MetaAutoPoster reporter
UI / Mobile
New
- Provide GUI/mobile-friendly reporting views
monthly fan process
monthly fan process
New
PROGRAM: monthly_fan_process PURPOSE The monthly fan process is a downstream fan-engagement workflow. Its job is to consume the already-created monthly collector CSV and produce downstream fan-engagement artifacts, including: - monthly narrative output - newsletter files
Reels Poster
Cloud Readiness
New
- Prepare poster for cloud execution (environment, secrets, networking) - Ensure portability beyond single-machine launchd execution
Reels Poster
Error Notification
New
- Implement alerting for failures (email or other mechanism) - Surface actionable error context (not just failure counts)
Reels Poster
Launchd / Execution Stability
New
- Resolve intermittent failures: - Dropbox/API connectivity (DNS resolution failures) — not currently reproducing, monitor
Reels Poster
Multi-Client Support
New
- Extend poster to support multiple clients/accounts - Parameterize environment and credentials cleanly
Reels Poster
Reporting Enhancements
New
- Expand visibility into retries and pipeline health
Reels Poster
UI / Mobile Interface
New
- Develop GUI and/or mobile interface for: - Monitoring posting activity - Viewing errors and reports - Triggering manual runs
Renamer
Renamer
New
Renamer — Roadmap ---------------------------------------------------------------- Current status - 2026-04-19: Renamer is in steady-state operation. All roadmap items completed and moved to Renamer README: - Process scoring queue events
RockerTalker classifier
RockerTalker classifier
New
RockerTalker Classifier — Roadmap 1. Improve classification logic to eliminate wrong labels (ROCK mislabeled as TALK and TALK mislabeled as ROCK), even if UNKNOWN increases. 2. Refine decision rules to require multiple confirming signals for ROCK classification (reduce false positives from single metrics like flatness or centroid). 3.
Selector
Decommission legacy selector system (future)
- After all consumers are migrated - Remove legacy selector and queue manager - Archive all legacy artifacts - Confirm shim subsystem is sole production system
Selector
Emit selection-based scoring events
- On each selection, append a row to scoring_events_queue.csv - Read event definitions from Scoring_Events config - Implement "Selected" event (e.g., -5% score delta) - Write one scoring event per selection - Use Dropbox-relative path in scoring queue
Selector
Implement score-weight-aware queue population
- Read posting pool configuration from JITRBeats_Posting_Pools - Support Score Weight per pool - Pool weight determines distribution across folders - Score weight determines which files are selected within a pool - Higher score weight biases toward higher-scored clips - Lower score weight allows more randomness
Selector
Implement shim queue contract
- Queue name: shim_selector_queue.csv - Location: $JITR_STATE/ShimSelector/ - Fields: - picked_path (Dropbox-relative) - pool_label - Selector resolves picked_path to absolute path using $DROPBOX_ROOT - No absolute paths stored in queue
Selector
Migrate consumers to shim selector (future)
- After shim subsystem is stable in production - Migrate consumers one at a time (posters, renamer, etc.) - Validate each migration using standard release process
Selector
Schedule shim queue manager
- Create launchd job for ShimSelector_queue_manager.sh - Ensure queue is maintained automatically - Validate logging and execution in non-interactive environment - Confirm stable behavior over time
Selector
Stand up shim-aware selector subsystem in production
- Build ShimSelector_pick_one.sh and ShimSelector_queue_manager.sh as a complete, independent subsystem - Ensure subsystem is environment-agnostic (no machine-specific paths) - Run subsystem in parallel with existing selector system - Do not migrate consumers in this step
Selector
Validate end-to-end shim subsystem behavior
- Queue manager builds valid queue - Selector pops queue and returns valid absolute path - Selector writes ledger entry (relative path) - Selector emits scoring event - Score-weight logic influences selection - No dependency on legacy selector or queue
Shim Checker
Current
New
1. Identify non-portable programs (Prod and Dev) - Scan programs in: - scripts/prod - scripts/dev - Detect hard-coded, machine-specific paths - Ensure programs rely on: - $DROPBOX_ROOT - $GDRIVE_ROOT
Shim Checker
Notes
New
- Purpose: enforce portability and environment independence across JITRBeats - This is an audit tool only (no automatic fixes)
Spotlight videoPipeline
Spotlight videoPipeline
New
Spotlight_videoPipeline — Roadmap 1. Define metric semantics in English - Posting inventory (ready-to-post clips) - Raw video pipeline (future clip capacity) - Clarify status meaning (green / yellow / red) 2. Reconsider conversion effectiveness metric
TikTok filler
TikTok filler
New
tiktok_filler Roadmap (none) Completed (promoted to prod) 2026-04-18 Item: (Retired) Fix PROD permissions to standard (755, wheel) Retired via JITRBeats standards amendment 2026-04-18. Dropbox- backed prod is filesystem-constrained to group=staff (chown to
TikTokAutoPoster
Completed (promoted to prod)
New
### 2026-04-15 (2) — Reporter now reads ShimSelector ledger Closed the real data-pipeline gap exposed by release (1). Changed LEDGER to $JITR_STATE/ShimSelector/shim_selector_ledger.csv; dropped the category_from_path derivation in favor of reading pool_label directly; dropped the picked → pool_resolved fallback.
TikTokAutoPoster
Notes / standing state
New
### Pending DEV work on reporter (transitional, low priority) There is a WIP edit on scripts/dev/TikTokAutoPoster_reporter.sh that filters on both TikTok and tiktok_manual poster labels and shows separate counts in the report body. This was staged 2026-04-16 in anticipation of the filler chat relabeling its shim-selector calls from --poster TikTok to --poster tiktok_manual.
TikTokAutoPoster
Open items (priority order)
New
### 1. Rebuild the TikTok Content Posting API approval demo The app has been denied twice by TikTok with no clear feedback. Prior submissions likely read as "fully automated" — which TikTok treats as disqualifying. Re-record the demo framing the system as: - Creator-owned content (Hecojeni's own masters) - Human-in-the-loop: selection → review → post - Compliant with TikTok's developer policies Business value: unbloc…
video text overlay
Future
New
- Scan video library for clips without text - Generate transcripts for those clips - Derive short hook text from transcripts - Automatically apply overlays so all videos include text
video text overlay
In Progress / Next
New
- Improve text display so hooks “pop” more (e.g., motion/scrolling, stronger visual treatment)
VideoResizer
VideoResizer
New
# VideoResizer — Roadmap # Location: $JITR_SCRIPTS/dev/VideoResizer.sh # State: DEV only (never promoted to PROD). Completed: probe parsing fix + progress feedback (2026-04-20). # Priority order — finish P1 before P2, unless Jeff changes priorities. [P1] Validate full-library dry-run classification (IN PROGRESS 2026-04-20) Why: Proves the probe fix works at scale and gives us real PASS/FAIL/SKIP numbers
VideoSelector
Notes
New
Current production state after release closeout: - Shim selector is the active production direction - Shim queue-manager is the only active scheduled selector launchd job - Legacy queue-manager launchd job has been disabled and archived - Identified active PROD consumer migration is complete for YouTube, Reels, Facebook, and the already-shimmed TikTok refiller - The next frontier is controlled legacy wrapper/script r…
VideoSelector
Priority 1 — Migrate consumers from legacy selector to shim selector
New
Remaining work: - Confirm no hidden/manual consumer still calls VideoSelector_select.sh or the legacy selector scripts outside the active poster/file-management paths already checked. - Keep VideoSelector_select.sh temporarily as a rollback-only legacy surface until scoring/Renamer hardening and rollback posture are settled. - Handle DEV legacy selector scripts deliberately after the rollback-only window closes.
VideoSelector
Priority 10 — Bucket rollup reporting of actual selections over time windows
New
Intent: produce an executive-readable breakdown of what the selector actually picked over rolling time windows (24h, 7-day, 30-day), grouped into three buckets: - AI (any variant — pool labels containing "AI") - Pronounce Hecojeni - The rest (everything else) This complements the existing pool-by-pool actual-vs-expected table in Selector_reporter.sh — that's useful for tuning individual weights, while the bucket roll…
VideoSelector
Priority 2 — Selector consumer inventory and migration memo
New
Remaining work: - Produce a concrete list of consumers and their current selector entrypoint - Create migration note showing old path vs new path - State clearly that migration is intended to be a selector path swap for callers - Capture any consumer-specific exceptions discovered during migration Inventory started 2026-04-11: - YouTube_poster.sh called legacy Selector_pick_one.sh directly; migration completed in DEV…
VideoSelector
Priority 3 — Scoring integration validation / hardening
New
Remaining work: - Confirm scoring events continue to emit in PROD across real consumer runs - Validate event format, identifiers, and deltas - Check for missing or duplicated scoring writes over time - Add reporter/observability only if needed after real-use review Current evidence - 2026-04-12: - ShimSelector producer-side scoring is working in PROD consumer paths.
VideoSelector
Priority 5 — Queue distribution quality / de-bunching
New
Remaining work: - Reduce visible streaking from FIFO consumption of weighted batches - Evaluate shuffle, interleave, or soft-cap approaches - Validate improvements against actual operational behavior Business value: - Improves perceived randomness - Reduces repetitive posting clusters - Produces healthier downstream content distribution
VideoSelector
Priority 6 — Pool ↔ filesystem auto-sync with email notification
New
Intent: When new folders appear under TikTok and Reel Clips, or when folders are removed or renamed, ShimSelector_pools.csv should stay in sync automatically — and Jeff should get an email describing every change so nothing is silent. Remaining work: - Build a pool auto-sync program that: - Walks the TikTok and Reel Clips filesystem roots - Reads $CFG/ShimSelector_pools.csv - Detects: new folders on disk not in confi…
VideoSelector
Priority 7 — Discontinue legacy pool config files
New
Context (2026-04-19): the live pool config is $CFG/ShimSelector_pools.csv. Multiple legacy pool config files still sit in $CFG/ that are no longer read by anything in the shim pipeline but create operator confusion and carry stale weights: - $CFG/youtube_unified_pools.csv (Mar 25) — the original YouTube-era unified pool file - $CFG/JITRBeats_Posting_Pools.csv (Mar 12) — the cross-poster successor - $CFG/JITRBeats_Pos…
VideoSelector
Priority 8 — Master song list sync (mp3 recordings ↔ song folder + pool config)
New
Source of truth: .mp3 files under the Hecojeni Recording Files location (exact path to be confirmed during implementation — likely $DROPBOX_ROOT/Just in Time Records/Artists/Hecojeni/Recording Files/ or similar). Intent: every song that has a recorded .mp3 should have both a matching subfolder under TikTok and Reel Clips/Song Specific Videos/ AND a pool config entry in ShimSelector_pools.csv.
VideoSelector
Priority 9 — Released Music AI subfolder sync
New
Source of truth: songs under the Released Music location, format yyyy/songname/ (exact path to be confirmed during implementation). Intent: every song that has been officially released should have an <SongName> - AI subfolder under Song Specific Videos/<SongName>/, with a corresponding pool config entry.
WeeklyReporter
WeeklyReporter
New
WeeklyReporter — Roadmap Purpose Create a weekly, fact-based system report that reflects current production capabilities, recent releases, and forward roadmap. This report is intended for executive visibility and external stakeholders (including investors). Scope 1. System Inventory - Count of programs in dev and prod
Weights recommender from scores
Add a stability-and-coverage monitoring report
New
What: a small companion report (daily or weekly) that does not change weights but describes: events per pool over the last 30 days, week-over-week change in suggested weight per pool, and count of pools with fewer than N events (where N is the data-confidence threshold we pick).
Weights recommender from scores
Build stage-2 mechanism
New
What: a new script (or new mode of the recommender) that reads .suggested, compares to active config, applies changes that pass the item-5 gate, logs every change with before/after, writes a daily email summary. Business value: operational automation — weights stay current without daily human intervention. Prerequisite: item 5 designed and approved. Released through full 13-step discipline.
Weights recommender from scores
Design stage-2 auto-apply criteria
New
What: decide the gate that lets the recommender write to the active config without human review. Expected components: - Minimum events per pool for the pool to be auto-adjusted (pools below threshold stay pinned at current weight) - Maximum daily or weekly change per pool (no lurch) — e.g.
Weights recommender from scores
Observe and stabilize in stage-1 (ongoing, no code yet)
New
What: watch the daily .suggested file and the $JITR_REPORTS/Weights/ reports for a sustained period. Track: - How many engagement events land per pool per week - How stable the recommendations are week-over-week for the same pool - Whether the pools most boosted by data feel right to Jeff's editorial intuition - Whether the pools most cut by data feel right to Jeff's editorial intuition Business value: builds shared…
Weights recommender from scores
Open design questions (to think about, not to act on yet)
New
- Does the X (Twitter) scorer eventually produce X_Engagement events, and how does X's signal compare in volume and variance to IG/YT/FB? Affects item 2 sizing. - Does TikTok auto-posting go live, producing TT_Engagement? If so, how does it weight relative to the other platforms? - Should different platforms carry different weights in the recommender (e.g.
Weights recommender from scores
Overall direction: from "recommend" to "set"
New
Today is stage 1 (recommend only). The recommender writes JITRBeats_Posting_Pools.csv.suggested every morning. Jeff reviews and hand-adopts any change into the active config. The long-term goal is stage 2 (machine sets weights) — the recommender applies its suggestions to the active config automatically, inside guardrails, with Jeff retaining override and rollback. The roadmap below is the path to get there.
Weights recommender from scores
Revisit half-life as signal density grows
New
What: current half-life is 30 days, chosen for sparse data. With denser data a shorter half-life (14 days) makes the recommender more responsive to recent performance shifts. With much denser data, maybe an even shorter one. Business value: matches recommendation responsiveness to the rhythm of audience feedback, once we see how fast signals actually change.
Weights recommender from scores
Stage-2 rollout with safety net
New
What: three phases in order: - Shadow mode: auto-apply runs but writes to a shadow config file, not the active one, for a set period (e.g. 30 days). Jeff compares the shadow to the active daily. - Canary: auto-apply runs against the active config but only for a designated subset of pools (e.g. "Videos with Errors" folders) for a set period. - Full cutover: auto-apply is live for all pools that pass the stage-2 gate.
Weights recommender from scores
Widen dynamic range between top and average performers
New
What: the current performance multiplier is perf = 1 + avg_delta_pct / 100, which keeps top performers within ~20% of average. Once data density is higher, amplify via perf = 1 + k × avg_delta_pct / 100 with k somewhere in 2–3. A +20 avg_delta then becomes perf=1.40 or 1.60, so the top performer pulls materially further from the pack.
X Poster
Priority Order
New
### 1. Safer restart pattern for future re-enable Business value: when the X account is available again, reposting resumes more carefully and does not reproduce the pattern that may have contributed to suspension. - Fix the handoff from YouTube_poster so X_Poster no longer parses the last line of youtube_poster.log (YouTube_poster now logs extra cadence/post-text lines after upload).
YouTube poster
Priority Order
New
### 1. YouTube-specific copy curation Business value: while JITRBeats currently treats all social platforms identically, YouTube audiences and YouTube Shorts norms differ from FB/Insta. Platform-tuned copy will feel more human and perform better than reused cross-platform copy. First step toward recognizing platform differences across JITRBeats broadly.
YouTube reporter
Priority Order
New
None.
YouTube upload one
Priority Order
New
### 1. OAuth regeneration helper (deferred) Business value: when the stored token expires or is revoked, restoring upload capability should not be a scramble. - No active jitr_youtube_oauth.sh helper exists; the archived helper uses constructs incompatible with our current paste-proof and launchd standards.
JITRBeats · generated automatically · items touched within 30 days show a New badge.