Перевірені докази для рішення
Це редакторський шар над повним інвентарем ../metrics/runs.json. Тут наведено конкретні позитивні й негативні факти, які використано у рекомендації. Вони не є повним переліком усіх функцій кожної відповіді. Позначення моделей — лише blind ID.
E01
Оксана / оцінка 3, M1 проти M2–M8. Відображений текст запиту однаковий: запис і транскрибація дзвінків, самарі, звіти, Google і Telegram. M1 дає 10–12 тижнів, $42–53K, ролі та етапи; припускає web, одного провайдера телефонії або upload, зовнішні speech-to-text/LLM. Інші сім результатів — insufficient-context. Немає підстав називати їхні відмови виправданими браком будь-якого конкретного scope. Причину fallback без raw логів не встановлено.
Джерела: M1, M2, решта — інвентар усіх запусків.
E02
Юра / оцінка 2. M1 дає 13–16 тижнів, $64–82K, 5–6 ролей для «Uber для майстрів». Числа та заголовок перевірено на render. Припущення обмежують MVP одним містом, готовими картами, ручною оплатою майстру без gateway. Це придатна початкова гіпотеза, але її confidence «Середній» варто знизити через широкий inferred scope. M2–M5, M7–M8 показують fallback, M6 — технічну помилку.
Джерела: M1, перевірене зображення, M2.
E03
Алекс / оцінка 1, M1. Явно розведені MVP $82–102K / 15–18 тижнів, вужчий пілот під $45K та наступний повний продукт — додаткові $160–220K / 6–9 місяців. Офлайн-конфлікти, міграція 12k обладнання + 40k заявок, приватність і deferred QuickBooks/SaaS пояснені. Це сильне розмежування scope; правильність цін не підтверджена. Summary містить три речення, тоді як поточний контракт вимагає два.
Джерело: M1.
E04
Алекс / оцінка 1, M2/M4/M7. У narrative описано ранній пілот, але головна картка «Тижнів до запуску MVP» показує строки всього продукту: M2 — 36–44, M4 — 35–42, M7 — 32–42. Це scope/UI-конфлікт, а не доказ завищення ціни. M2 прямо називає MVP $43.1–45K / 14–16 тижнів і повний total $142–172K; читач бачить різні горизонти на одному екрані.
Джерела: M2, M4, M7.
E05
Алекс / оцінка 1, M8. Є MVP $41.5–47.8K / 14–16 тижнів і deferrals QuickBooks/SaaS/AI; окремої числової оцінки повного продукту, прямо запитаної клієнтом, немає. Синхронізація врахована, але коротша відповідь не є еквівалентом повного покриття.
Джерело: M8.
E06
Оксана / оцінка 2, усі моделі. Запит — профілі, оголошення книжок, фільтри, оформлення покупки, історія та контакт продавця. Gateway і автоматичні платежі не задані. M2 явно виключає gateway, split/commission і доставку, пропонує прямі домовленості; M1/M3/M4/M5/M6/M7 додають стандартну платіжну інтеграцію як припущення; M8 залишає альтернативу gateway або оплата при отриманні. M4 додає комісійну модель. Це різний scope, тому $16.5–20.2K M2 не доводить кращу точність проти $42–57K M1 або $52–71K M4. Припущення прозорі, але gateway може збільшувати початковий бюджет без запиту клієнта.
Джерела: M2, M1, M4.
E07
Математична прозорість M2 — перевірені приклади. Calmi: $107,800–129,700 точно відтворюється з шести груп годин × ставок; сумарні 2,660–3,200 годин також сходяться. Energy: повний продукт $180,800–225,500 та MVP $74,300–92,050 сходяться з наведених годин. Coworking: $34,820 округлюється у hero до $34.8K. Odoo staffing: (30×60 + 5×30 + 3×35)×12 = $24,660. Це перевірка п’яти розрахунків у чотирьох відповідях, а не підтвердження достатності цих годин.
Джерела: Calmi, Energy, Coworking, Odoo.
E08
Віталік / Energy, M2. Відповідь не гарантує відновлення довільного креслення: потрібен масштаб, ручне редагування й підтвердження аудитора. Пряме подання до ЄДЕССБ не включено без підтвердженого API. Названі контрольні приклади, версіонування методики та human approval. Сильне обґрунтування конкретної невизначеності. Hero знову містить повний продукт під загальним MVP-label.
Джерело: M2.
E09
Алекс / підбір 1, M2 проти M4/M6/M7/M8. M2 дає конкретні середні години, ставки, $24,660 та умову доступного Odoo API. M4 рекомендує full-time Senior по $60/h і додаткові QA/UIUX, не пояснивши fit у $25K; за припущення 40h/week лише Senior коштує $28,800 за 12 тижнів. M6/M7/M8 описують склад, але не дають співставного розрахунку завантаження під цей cap. Це проблема пояснення бюджету, а не оцінювання ставок COWO-кандидатів.
Джерела: M2, M4, M6, M7, M8.
E10
Юра / GearShare. M1–M6 показують технічну помилку; M7 і M8 дають оцінки. M7 докладніше враховує Google Calendar, ставки комісій 10%/5%, депозит 20–100%, payout 48h із матеріалів. M8 дає коротший блок припущень про gateway/KYC/delivery; явної деталізації цих комісій, Google Calendar і promotion у результаті немає. Жодна з двох не розв’язує явно конфлікт тексту «iOS+Android+web на старті» з flow «Android first, iOS later, web не потрібен» та card/cash. M8 трактує hold «до 7 днів із продовженням», тоді як policy прямо говорить про повторну авторизацію; підтримку конкретного провайдера не перевірено й гарантувати її за корпусом не можна.
Джерела: M7, M8, flow, policies, локальні admin-log MD M1–M6.
E11
Юра / склад. M1–M7 показують fallback на запит зі sketch; M8 variant 1 — технічну помилку, variant 2 — вкладення/сторінку без видимого результату. Sketch містить Android Zebra TC21, офлайн, 5 складів, ~20k SKU, ~40 користувачів і 1C. Загальна «нестача контексту» не доводить, що ці вимоги були прочитані. Немає успішного результату, придатного для порівняння image-only scope. Варіант 2 не називається підтвердженим timeout лише за скриншотом.
Джерела: скетч, M1, M8 v1, M8 v2.
E12
Саша / оцінка 3 — непорівнюваний вхід. M1: Web3. M3: транскрибація дзвінків. M2/M4/M5/M6/M7/M8: ToolShare у заголовку та транскрибація в описі. M3 дає estimate; інші fallback. Це не head-to-head перемога M3, бо введені тексти відрізняються змістовно.
Джерела: M1, M2, M3.
E13
Свят / оцінки 2–3. В усіх восьми моделях fallback: custom-furniture order management для трьох робочих місць; WooCommerce delivery calculator із редагованими тарифами/святами. Це конкретні software needs із detail, достатні для гіпотези за поточним prompt. Generic fallback не називає потрібних саме для цього процесу фактів. Результати свідчать про спільну продуктову прогалину; вони не локалізують її в LLM або input gate.
Джерела: case 2, case 3.
E14
Оксана / обидва підбори. 16/16 видимих результатів — fallback, а request mode показує «Оцінка проєкту» попри текст пошуку розробника. Не зараховуємо це як невалідну відповідь на коректно pinned matching. Але для клієнта outcome непридатний; одна заміна моделі не має показаної переваги в цих комірках.
Джерела: підбір 1 M1, інвентар runs.json для всіх M1–M8.
E15
Саша / Vaultix. M2/M5/M6 обмежують штрихкод і ручну ринкову ціну; M1/M3/M4/M8 припускають зовнішні товарні каталоги. M7 у hero обіцяє автоматичну оцінку, потім у assumptions допускає ручну/напівавтоматичну ціну без доступного API. Нове джерело цін не задано, тому цю різницю потрібно узгодити до продажу scope. M8 стверджує «витрати майже вдвічі» без локального обґрунтування такого коефіцієнта.
Джерела: M2, M5, M7, M8.
E16
Оксана / Calmi. M2/M3/M5 прямо описують editable food recognition/fallback, приватність і safe-use. M5 стисло, але явно включає user confirmation, deletion і audit trail. M8 описує food/health/subscriptions/privacy, але формула «шифрування на рівні ключів доступу» нечітка; у результаті немає такого ж явного переліку low-confidence fallback, safe-use для minors/pregnancy та audit trail. Це пропуск у поясненні scope, не висновок про небезпечну реалізацію майбутньої системи.
Джерела: M2, M3, M5, M8.
E17
Формат і причинність. M5 має однореченнєві summaries в Алекс / оцінка 1 та Оксана / оцінка 2; M1 має три речення в Алекс / оцінка 1. Це видимі невідповідності теперішній вимозі двох речень. Raw JSON не збережено: parseability/schema compliance не оцінюється. PNG Віталіка / M2 / підбір 2 підтверджує технічну помилку, але не її причину.
Джерела: M5 Алекс, M5 Оксана, PNG-транскрипція.
E18
Юра / підбір 1, M1. Відображено оцінку CRM/магазину замість підбору команди; admin notes згадують потребу явно вибрати matching. Це wrong-scenario outcome, а не успішний підбір. M3/M6 у цій комірці мають технічні помилки; M2/M4/M5/M7/M8 — matching.
Джерела: M1, нотатки M1, повний інвентар запусків.