# Case: workflow „postęp z niedocenianymi szkodami"

Materiał referencyjny do opisu **konstrukcji odpowiedzi** na otwarte pytanie badawcze
za pomocą wieloagentowego workflow Claude Code (tryb ultracode). Pełny skrypt i opis konstrukcji workflow; publikacja i streszczenie: fiedoruk.pl/pytanie-ai-odpowiedz.html

- **Data uruchomienia:** 2026-06-27
- **Skrypt:** [`progress-harms-rigorous-eval.workflow.js`](./progress-harms-rigorous-eval.workflow.js) — kopia 1:1 wersji uruchomionej
- **Model:** Opus 4.8 (1M), effort xhigh, dynamic workflow orchestration
- **Skala:** ~91 agentów rozłożonych na 6 faz (concurrency cap ~10–14, total lifetime do 1000)

## Pytanie wejściowe

> Czy istnieją wynalazki/technologie/zmiany społeczne powszechnie uznawane za postęp
> (lub neutralne), które mogły mieć istotne, ale niedoceniane negatywne skutki dla
> dobrostanu? Wymagana: krytyka samego pytania → definicja osi szkody → 3–5 kandydatów
> (mechanizm / argument za / kontrargument / jakość danych / pewność) → ranking tylko
> jeśli uzasadniony → rejestr neutralny, bez ozdobników.

## Architektura (mapowanie wymagań pytania → fazy)

| Faza | Co robi | Agenci | Wzorzec |
|------|---------|--------|---------|
| **1. Framing** | 12 niezależnych krytyk *postawienia pytania* (12 różnych soczewek: ukryte założenia, is/ought, kontrfaktyk, biasy nostalgii vs presentism, niewspółmierność osi…) → 1 syntezator scala i definiuje 5–7 osi dobrostanu | 12 + 1 | multi-modal sweep + barrier→synteza |
| **2. Generate** | 24 generatory kandydatów, każdy w innej domenie (komunikacja, żywność, chemia, sen, finanse…) → 1 kurator dedup/klaster + shortlist 8 + jawna lista odrzuconych mitów | 24 + 1 | diverse-lens fan-out + completeness via pokrycie domen |
| **3+4. DeepDive→Verify** | `pipeline()` po 8 kandydatach: każdy dostaje pogłębioną analizę (z opcjonalnym researchem web), a gdy tylko skończy — 4 adwersaryjnych weryfikatorów (przyczynowość / biasy dowodów / kontrfaktyk-steelman / skala-bazowa) atakuje równolegle | 8 + ~32 | **pipeline** (bez bariery) + perspective-diverse adversarial verify |
| **5. Rank** | 7 sędziów ocenia *czy ranking jest w ogóle uzasadniony* (różne priorytety + jeden domyślnie sceptyczny) → 1 syntezator: ścisły porządek vs warstwy vs „nie da się" | 7 + 1 | judge panel + barrier→reconciliation |
| **6. Synthesize** | draft PL (ścisła 5-punktowa struktura) → 3 krytyków (nadmierna pewność / rejestr+struktura / fakty+konsensus zdrowotny) → integrator finalnego raportu | 1 + 3 + 1 | draft → completeness critics → integrator |

## Kluczowe decyzje projektowe (to, co warto opisać w case)

1. **Krytyka pytania jako osobna faza przed generowaniem treści** — wymóg „zacznij od
   krytyki postawienia pytania" zmapowany na 12 niezależnych agentów, nie jeden akapit.
   Różnorodność soczewek > jeden „mądry" przebieg.
2. **Bezstronność wymuszona strukturalnie, nie tylko promptem** — dla każdego kandydata
   osobny *steelman obrony technologii* (`kontrfaktyk-steelman`) i osobny atak na
   przyczynowość. Teza nie może „wygrać" przez samo jej powtórzenie.
3. **Twardy guardrail anty-dezinformacyjny** — `CONTEXT` zasada #3 + faza generacji
   (`excludedNotable`) + krytyk #3 wykluczają obalone mity zdrowotne (szczepionki,
   fluoryzacja) i traktują je jako kontrprzykład dla narracji „postęp = ukryta szkoda".
4. **Kalibracja pewności jako pole schematu** (`confidence` enum niska/średnia/wysoka),
   obniżana przez werdykty weryfikacji — pewność jest danymi, nie ozdobą.
5. **Ranking warunkowy** — faza 5 może orzec „nie da się rzetelnie rankować" (niewspół-
   mierność osi). Spełnia wymóg „nie wskazuj zwycięzcy, jeśli dane nie pozwalają".
6. **`pipeline()` zamiast bariery** między DeepDive a Verify — kandydat weryfikuje się,
   gdy tylko jego analiza gotowa; brak marnowania wall-clocku na najwolniejszy deep-dive.
7. **Structured output (JSON Schema) na każdym etapie pośrednim** — walidacja na warstwie
   tool-calla, brak parsowania tekstu; tekst surowy tylko na draft/integrator (finalny PL).

## Wzorce z biblioteki Workflow użyte w tym skrypcie

- multi-modal sweep (24 domeny generacji, 12 soczewek krytyki)
- perspective-diverse adversarial verify (4 różne soczewki ataku, nie 4× to samo)
- judge panel + reconciliation (ranking)
- completeness critics → integrator (synteza)
- pipeline (DeepDive→Verify bez bariery), barrier tylko tam gdzie potrzebny cross-item kontekst (synteza framing, shortlist, ranking)

## Jak ponownie uruchomić / iterować

```
Workflow({ scriptPath: "./progress-harms-rigorous-eval.workflow.js" })
```

Skrypt jest sparametryzowany tylko przez stałą `CONTEXT` (teza) + tablice soczewek/domen
— by użyć go do innego pytania, podmień `CONTEXT`, `FRAMING_LENSES`, `GEN_DOMAINS`,
ewentualnie `VERIFY_LENSES`. Reszta orkiestracji jest generyczna dla zadań typu
„rygorystyczna, bezstronna ocena otwartej tezy".