Проєкт 2: 14-денний мультиплатформний контент-пакет

Завдання

Створіть для синтетичного Northstar Studio 14-денний пакет із восьми запланованих одиниць контенту: по дві для Instagram, Facebook, LinkedIn і TikTok. Вони мають походити з одного перевіреного message core, але мати різні ролі, композицію, темп і спосіб взаємодії. Реальні акаунти, публікація, рекламний бюджет, контакти й клієнтські дані заборонені.

Що передати

1. README із рішенням і межами на 500–800 слів.
2. Message core та facts/claims із джерелами й unknown.
3. platform-plan.csv: 8 рядків, дати D01–D14, роль, формат, CTA і метрика.
4. Пакет текстів, static/document/video plans і manifest версій.
5. Accessibility, rights та privacy checklist для кожного asset.
6. QA evidence, decision log і test plan зі статусом not_run.

Непрохідні порушення

Проєкт повертається без оцінки, якщо містить персональні чи production-дані, непідтверджені гарантії, сторонній asset без права використання, приховану платну співпрацю, недоступний критичний зміст або вигадані результати. Посилання на «так роблять усі» не є доказом.

Самоперевірка

Пройдіть усі вісім рядків від брифу до export: claim references, платформа, роль, формат, alt/captions, rights, owner, QA та decision. Відкрийте фактичні файли на вузькому екрані. Переконайтеся, що строки запису, тривалість, невідома дата й CTA не суперечать одне одному. Зафіксуйте, що не перевірено через відсутність реальної публікації.

14-денна логіка

Розкладіть вісім одиниць між D01 і D14 так, щоб кожна мала самостійну роль: відповідь на питання, пояснення методу, демонстрація, професійний висновок або контрольований варіант тесту. Календар не повинен удавати фактичні дати, якщо робота виконується поза запуском. D01–D14 — відносні навчальні позначки.

Поясніть залежності. Наприклад, відео не переходить у ready раніше за transcript, captions і rights check. Варіант B не переходить у test-ready, доки незмінні фактори не записані. Якщо одна помилка змінює message core, поверніть на перевірку всі вісім похідних, а не тільки файл, у якому її помітили.

Захист рішення

У README обґрунтуйте, чому кожній платформі призначено саме ці ролі й формати, які твердження залишилися незмінними, які ризики зупиняють публікацію та які дані потрібні для наступного рішення. Не захищайте роботу прогнозом охоплення. Захист має показати ланцюг від задачі й evidence до адаптації та перевірки.

Reviewer перевіряє не художній смак, а відтворюваність: чи може інша людина знайти джерело факту, потрібну версію, owner, QA evidence і правило рішення. Якщо щось ще не виконано, статус має прямо це показувати. Чесний not_checked кращий за вигаданий pass.

Прийняття: щонайменше 80/100 і жодного critical privacy, rights, accessibility, deception або brand-safety blocker.