@harness-lab/cli 0.2.8 → 0.3.0

package/assets/workshop-bundle/content/codex-craft.md

@@ -0,0 +1,190 @@
+# Codex Craft
+
+> Tool-specific fluency to sit on top of the agent-agnostic harness method.
+
+Harness Lab teaches a method that transfers across coding agents: Codex, pi, Claude Code, Cursor, Aider. The method is agent-agnostic by design. This document is the other half: the **Codex-specific craft** that the method assumes you already know, but that nobody teaches you in order.
+
+If something in this doc contradicts the live Codex documentation, trust the live docs. This doc is a teaching artifact, not a specification. Last verified against Codex CLI in April 2026 — re-verify before each cohort.
+
+---
+
+## 1. What the harness actually is in Codex
+
+In Codex, the "harness" is the union of four things:
+
+1. **The repo context the model can see.** `AGENTS.md`, files you name, files it reads on its own, the diff you built up this session.
+2. **The tool affordances the model can reach.** Shell access, file edits, network calls, Playwright probes. Each affordance has an approval posture you chose.
+3. **The approval and sandbox posture you picked when you started the session.** This determines what Codex can do without asking you.
+4. **The feedback loop.** Tests, type checks, compiler errors, your review. This is how the agent learns it made a mistake in this session.
+
+All four are yours to engineer. None of them are optional. When a harness feels "off", it's almost always because one of these four is underspecified.
+
+---
+
+## 2. Approval modes — pick deliberately, not by default
+
+Codex CLI sessions start with an approval posture. The common modes are:
+
+- **Suggest** — Codex proposes every shell command or file edit and waits for your `y/n`. Maximum control, maximum friction. Good for unfamiliar repos or risky work (migrations, production-adjacent changes).
+- **Auto-edit** — Codex can edit files without asking, but still asks before running shell commands. This is the right default for most feature work in a repo you trust.
+- **Full-auto** (sometimes called "dangerously") — Codex can edit files and run shell commands without asking, inside the configured sandbox. Fastest; appropriate only when the sandbox is actually restrictive and the work is reversible.
+
+**Craft rule:** pick the approval mode *before* you start, based on the blast radius of the work — not during, because the mood of the session shouldn't drive safety posture. Write the mode into your `AGENTS.md` as a note for the next agent.
+
+**Common trap:** raising to full-auto for speed, then forgetting to lower it for the next task. Get in the habit of naming the current mode out loud, the way a pilot names airspeed.
+
+---
+
+## 3. Sandboxing — what "isolated" actually means
+
+Codex runs shell commands inside a sandbox. The sandbox constrains which directories are writable, whether network is allowed, and which binaries are callable. Exact defaults change between versions; what matters is the *posture* you should take:
+
+- **Assume the sandbox is part of the harness.** If it allows network and the task doesn't need network, narrow it. If it allows writes outside the repo and you don't need that, narrow it. Unused affordances are silent drift risks.
+- **Don't ask Codex to weaken its own sandbox.** If a step needs more capability, exit the session, reconfigure, and re-enter with the wider posture explicitly declared. Silent posture drift is the single most common "why did the agent do that" moment.
+- **Document the sandbox assumption in `AGENTS.md`.** One line: "This repo expects Codex with file writes inside `src/` and `tests/` only, no network, shell limited to npm/node." The next agent — human or AI — needs this to know what is load-bearing.
+
+---
+
+## 4. Context window as a resource, not a design aesthetic
+
+The model has a large context window. You do not have a large budget for putting things into it.
+
+**What this means in practice:**
+
+- **Not everything belongs in-context.** `AGENTS.md` should be a map — a short directory of deeper sources — not an encyclopedia. If it's 400 lines, it's a manual, and manuals don't fit in working memory.
+- **Progressive disclosure beats eager loading.** Point at files; let the agent read them when needed. A reference is cheaper than a copy.
+- **Long sessions decay.** After dozens of turns, constraints from the top of the session are in danger of being silently forgotten. Re-surface rules before they matter, not after the agent violates them.
+- **The expensive prompt isn't the one you wrote. It's the one the agent is holding right now.** Every turn, the agent is re-reading the entire session. If there's noise in turn 5, it's still there in turn 50.
+
+**Craft rule:** treat context budget the way a performance engineer treats latency — as a constraint you measure and optimize, not a free resource you assume. The harness is partly a budget discipline.
+
+---
+
+## 5. Long-horizon drift and how to catch it
+
+Long-horizon drift is when the agent gradually stops honoring a constraint you set early in the session, because that constraint has scrolled out of its effective attention. It is the signature failure mode of longer Codex work.
+
+**Symptoms:**
+
+- The agent starts adding `any` types in a repo that explicitly requires strict typing.
+- The agent recreates a utility you told it to import from an existing module.
+- The agent silently stops writing tests for a kind of change it tested earlier.
+- The agent uses the wrong naming convention for the third of three similar files.
+
+**The harness move is not "remind the agent more loudly." It is:**
+
+1. **Put the constraint in a place the agent re-reads.** `AGENTS.md`, a pre-commit check, a test that fails loudly if the convention is broken. Don't rely on the constraint surviving in the scrollback.
+2. **Add a short re-anchor prompt before risky steps.** "Before you implement this, re-read `AGENTS.md` and state the three rules that apply to this change." This is a cheap, reliable drift detector.
+3. **Watch for the moment the agent starts "improvising" around a missing pattern.** That usually means it can't find the pattern any more, not that the pattern doesn't exist.
+
+**Craft rule:** drift is cheaper to prevent with repo artifacts than to correct with more prompting. Every time you correct the same drift twice, encode the constraint.
+
+---
+
+## 6. Before and after — a representative prompt pair
+
+The following is a **representative** comparison, not a live transcript. It is constructed from patterns commonly observed in Harness Lab cohorts. Your actual output will differ; the shape of the difference is what matters.
+
+### The underspecified ask
+
+> Add a dashboard route that shows workshop instances with their current phase and team count. Make it look nice.
+
+What typically happens:
+
+- The agent picks a styling library it guesses is used in the repo (often wrong).
+- It invents a data shape for "instances" instead of reading the existing model.
+- It adds a route at a plausible but not conventional path.
+- It writes no test, because "make it look nice" did not ask for one.
+- You end up with 400 lines of code that almost fit and that you now have to reverse-engineer to reject.
+
+### The specified ask
+
+> **Goal:** Add a dashboard route listing workshop instances with their current phase and team count.
+>
+> **Context:** The instance model lives in `dashboard/lib/workshop-store.ts`. The existing route pattern is in `dashboard/app/workshops/page.tsx`. Styling uses Tailwind + the components under `dashboard/components/ui/`. Do not introduce a new styling library.
+>
+> **Constraints:**
+> - Read-only route. No mutations.
+> - Must work in file-mode storage (local dev) and neon-mode (production).
+> - Follow the existing route naming convention in `dashboard/app/`.
+> - If the instance list is empty, render the existing `EmptyState` component, not a bespoke fallback.
+>
+> **Done when:**
+> - The new page renders the expected columns.
+> - An e2e test in `dashboard/e2e/` loads the page and asserts at least one instance row when the demo data is present.
+> - Running `npm run build` in `dashboard/` produces no new TypeScript errors.
+>
+> Before you implement, read the existing route file and list the three patterns you're going to reuse. Do not start writing until I confirm.
+
+What typically happens:
+
+- The agent stops and reads the referenced files.
+- It lists the patterns it found. You catch any misreading in 30 seconds, before any code.
+- It proposes a plan. You either confirm or redirect — cheap.
+- It implements against the stated done criteria.
+- It runs the test and the build before claiming the work is finished.
+- The work either lands correctly in the first pass, or the feedback loop (test, build, review) catches the gap without you reading every line.
+
+**The difference isn't the wordcount.** It's that the second ask makes the agent's working context match your working context. The harness is what makes that match possible.
+
+---
+
+## 7. A failure-recovery moment
+
+This is the single thing missing from most agent demos: what happens when the agent drifts, and how the harness catches it.
+
+**Scenario (representative, reconstructed from a cohort session):**
+
+A team asked Codex to add a new `facilitator` role to an auth middleware. Codex implemented the change, ran the tests, and reported success. The tests were green. The dashboard worked in dev. Everything looked fine.
+
+The continuation team, the next afternoon, opened the repo and read `AGENTS.md`. One line said: "Any change to auth middleware requires a corresponding update to `docs/adr/` with a rationale." There was no new ADR. The team ran a grep for the new role and found it used only in the middleware — not in the one place in the dashboard that branches on role. The middleware change worked in tests because the test fixtures only exercised the happy path.
+
+**What the harness caught:**
+
+- The ADR rule in `AGENTS.md` caught the missing documentation.
+- The continuation team's "read first, diagnose second" discipline caught the incomplete usage.
+- Neither caught it by "prompting better." Both caught it because the repo carried constraints the morning team had encoded, and the afternoon team had a ritual for reading them.
+
+**The morning team's mistake wasn't prompting. It was trusting green tests as a completion signal in a repo where the real completion criteria lived in a doc they didn't re-read.** The fix is never "write a sharper prompt next time." The fix is either a test that would have failed, a rule that would have blocked merge, or a ritual that would have forced the check. All three are harness moves.
+
+---
+
+## 8. Tool selection — when to reach for what
+
+Harness Lab is agent-agnostic, but in practice you will pick a specific tool for each task. Heuristics:
+
+- **Codex CLI** — best for repo work with fast local iteration, especially when you want a sandbox and shell access. Strong for code generation, refactoring, debugging inside a repo you trust.
+- **Claude Code** — best for long, stateful sessions where you want the model to reason about the full shape of a problem and remember decisions across many turns. Strong for architecture work, careful reviews, careful migrations.
+- **pi** — best for terminal-native work that needs multi-model flexibility. Strong when you want to compare outputs or keep the harness lightweight and scriptable.
+- **Cursor / IDE-native tools** — best for fast edit-edit-edit loops inside a single file or small module, where you want the model's suggestions inline and do not need agentic control flow.
+- **Aider** — best for tightly-scoped edits against a known set of files, with git commits per turn.
+
+**Craft rule:** pick the tool based on the *shape* of the task, not the one you happen to have open. Every tool has an implicit harness; picking the tool is picking the harness.
+
+**None of this means you should switch tools mid-workshop.** Harness Lab cohorts should pick one tool for the day (usually Codex) so the learning accumulates. This section is about Monday morning, not about Saturday's workshop.
+
+---
+
+## 9. How to keep learning after today
+
+The Codex ecosystem ships new capabilities monthly. What's documented here will be partly outdated within the next release cycle. **Do not treat this doc as a frozen reference.** Treat it as a starting harness for your own reading practice:
+
+- Read the official Codex CLI release notes when they ship. The safety and approval posture changes there are the ones that matter most.
+- Subscribe to one practitioner newsletter who uses these tools daily (Simon Willison's blog is a dense source; there are others).
+- When you discover a failure mode in your own work, write it down in your own team's `AGENTS.md` or a runbook. Your team's harness should learn from your team's failures, not just from this doc.
+- Every quarter, re-read your `AGENTS.md` files with a skeptical eye. Delete anything that is no longer load-bearing. Simplicity is part of the harness.
+
+---
+
+## 10. The one-line summary
+
+You cannot prompt your way out of a bad harness. You can, however, engineer a harness that makes prompting mostly unnecessary.
+
+---
+
+## See also
+
+- [`coaching-codex.md`](../materials/coaching-codex.md) — one-page recipe card for the conversational moves that force plan-first work.
+- [`talks/context-is-king.md`](talks/context-is-king.md) — the workshop talk that introduces the method.
+- [`challenge-cards/deck.md`](challenge-cards/deck.md) — small interventions that install the habits during the build phases.
+- [`../workshop-blueprint/day-structure.md`](../workshop-blueprint/day-structure.md) — the full day architecture and the north-star question.

package/assets/workshop-bundle/content/facilitation/codex-setup-verification.md

@@ -9,7 +9,7 @@ Do 10:30 musí mít každý účastník jednu funkční cestu:
 - `Codex App`
 - nebo web fallback
 
-Cíl není perfektní instalace. Cíl je dostat každého co nejdřív do práce s agentem.
+Cíl není perfektní instalace. Cíl je dostat každého co nejdřív do práce s agentem.
 
 ## Rychlý start
 
@@ -27,7 +27,7 @@ Cíl není perfektní instalace. Cíl je dostat každého co nejdřív do práce
 2. Přihlaste provider nebo účet, který chcete používat.
 3. Otevřete repozitář.
 4. Spusťte `pi`.
-5. Načtěte workshop skill přes `/skill:workshop` a řekněte si o další krok.
+5. Načtěte workshop skill přes `/skill:workshop` a řekněte si o další krok.
 
 ### Windows / macOS
 
@@ -42,10 +42,10 @@ Použijte ho ve chvíli, kdy vás blokuje instalace, firemní politika nebo aute
 
 ## Troubleshooting checklist
 
-- Nejde login → přejděte na `App` nebo web fallback a pokračujte.
+- Nejde login → přejděte na `App` nebo web fallback a pokračujte.
 - Nejde CLI instalace → nenechte se blokovat déle než 7 minut.
-- Nejde otevřít repo → spárujte se s někým od stolu a vraťte se k tomu později.
-- Nevíte, co je další krok → v Codexu použijte `$workshop setup`. V pi načtěte `/skill:workshop` a řekněte si o setup pomoc.
+- Nejde otevřít repo → spárujte se s někým od stolu a vraťte se k tomu později.
+- Nevíte, co je další krok → v Codexu použijte `$workshop setup`. V pi načtěte `/skill:workshop` a řekněte si o setup pomoc.
 
 ## Facilitátorské rozhodnutí
 

package/assets/workshop-bundle/content/facilitation/master-guide.md

@@ -1,84 +1,84 @@
 # Facilitační průvodce
 
-## Otevření a welcome
+## Otevření a welcome
 
 ### Cíl
 
-Spustit den jako room-facing launch pro celý workshop, ne jako provozní brief k dopoledni.
+Spustit den jako společný start pro celý workshop, ne jako provozní brief k dopoledni.
 
 ### Klíčová message
 
-> „Dnes nejde o to být nejrychlejší. Jde o to postavit práci tak, aby ji cizí tým dokázal převzít a posunout dál.“
+> „Dnes nejde o to být nejrychlejší. Jde o to postavit práci tak, aby ji cizí tým dokázal převzít a posunout dál.“
 
 ### Co potřebuje zaznít
 
-- Nezačínáme tool demo ani soutěž v promptování.
-- Budeme se učit, stavět, předávat i přebírat. Ten oblouk dne je záměr workshopu.
-- Jde o práci s agentem tak, aby po vás zůstával použitelný kontext.
+- Nezačínáme tool demo ani soutěž v promptování.
+- Budeme se učit, stavět, předávat i přebírat. Ten oblouk dne je záměr workshopu.
+- Jde o práci s agentem tak, aby po vás zůstával použitelný kontext.
 - Odpolední část prověří, jestli repo opravdu unese převzetí dalším týmem.
-- Pokud nějaké důležité pravidlo žije jen v hovoru u stolu, ještě neexistuje.
+- Pokud nějaké důležité pravidlo žije jen v hovoru u stolu, ještě neexistuje.
 
 ### Doporučený sled beatů
 
 1. day-opening promise
 2. proč na tom záleží právě teď
 3. analogie typu Lego duck: stejné ingredience, různé použitelné výsledky
-4. krátká pohybová aktivace podle zkušenosti s AI agenty
+4. krátká pohybová aktivace podle zkušenosti s AI agenty
 5. první pracovní kontrakt pro Build fázi 1
 
 ### Lego-duck analogie
 
-Použijte ji krátce a věcně.
+Použijte ji krátce a věcně.
 
 Pointa:
 
 - stejný agent neznamená stejný výsledek
 - kvalitu neurčuje samotný model
-- kontext, mantinely a ověřování jsou součást výsledku
+- kontext, mantinely a ověřování jsou součást výsledku
 
-Nevést jako zábavnou odbočku. Vést jako vysvětlení, proč je harness engineering tvůrčí a inženýrská disciplína zároveň.
+Nevést jako zábavnou odbočku. Vést jako vysvětlení, proč je harness engineering tvůrčí a inženýrská disciplína zároveň.
 
 ### Pohybová aktivace
 
-Použijte krátké rozdělení místnosti podle aktuální zkušenosti s AI agenty:
+Použijte krátké rozdělení místnosti podle aktuální zkušenosti s AI agenty:
 
 - používám skoro denně
 - používám, ale opatrně
 - jsem spíš na startu
-- jsem skeptický, ale chci důkaz
+- jsem skeptický, ale chci vidět, že to funguje
 
 Pravidla:
 
-- ne dělat z toho networking kolo
+- ne dělat z toho networking kolo
 - stačí přesun a 2 krátké hlasy
-- pointa není seniorita, ale kalibrace místnosti a signál, že den je participativní
+- pointa není seniorita, ale kalibrace místnosti a signál, že den je participativní
 
 ### Co má facilitátor průběžně vracet
 
 - „Kde by to našel další tým bez vás?“
 - „Co je tady skutečně ověřené?“
-- „Je `AGENTS.md` mapa, nebo už se z něj stává dump?“
+- „Je `AGENTS.md` mapa, nebo už se z něj stává dump?“
 - „Jaký je další bezpečný krok pro cizího člověka nebo agenta?“
 
 ### První pracovní kontrakt
 
-Po launchi potřebuje místnost ještě jednu konkrétní věc:
+Po otevření dne potřebuje místnost ještě jednu konkrétní věc:
 
-- co má být po prvním build bloku opravdu vidět
-- co nestačí jen slíbit
+- co má být po prvním build bloku opravdu vidět v repu
+- co nestačí jen slíbit nebo dovysvětlit u stolu
 
 Do oběda má být vidět:
 
-- repo a `README`, které dávají smysl cizímu člověku
-- `AGENTS.md` jako krátká mapa
-- plan nebo jasně vedená implementační stopa
-- první explicitní check před dalším generováním
+- `README`, které dává smysl cizímu člověku
+- `AGENTS.md` jako krátká mapa, ne sklad všeho
+- plán kroků nebo jasně vedená implementační stopa, ze které je poznat další bezpečný krok
+- první explicitní ověření před dalším generováním
 
 ## Context is King talk
 
 ### Cíl
 
-Proměnit energii z openingu v přesnou tezi a čistý most do Build fáze 1.
+Proměnit energii z openingu v přesnou tezi a čistý most do Build fáze 1.
 
 ### Klíčová message
 
@@ -86,19 +86,21 @@ Proměnit energii z openingu v přesnou tezi a čistý most do Build fáze 1.
 
 ### Co potřebuje zaznít
 
-- Neučíme se lépe promptovat. Učíme se postavit repo a workflow, ve kterém agent i cizí tým dokážou bezpečně pokračovat.
-- `AGENTS.md`, skills, runbooky a checks jsou týmová infrastruktura, ne polish navíc.
-- Team lead nestojí modelu za zády a nediktuje další větu každých třicet sekund.
-- Po talku se tým vrací k repu s mapou, planem a prvním checkem, ne s lovem na chytřejší prompt.
+- Neučíme se lépe promptovat. Učíme se postavit repo a workflow, ve kterém agent i cizí tým dokážou bezpečně pokračovat.
+- `AGENTS.md`, skills, runbooky a ověřovací kroky jsou týmová infrastruktura, ne polish navíc.
+- Team lead nestojí modelu za zády a nediktuje další větu každých třicet sekund.
+- Po talku se tým vrací k repu s mapou, plánem kroků a prvním ověřením, ne s lovem na chytřejší prompt.
 
 ### Mikro-cvičení
 
+Tohle je krátká facilitátorova ukázka, ne zadání pro celý room.
+
 Použijte stejný malý task ve dvou podmínkách:
 
 1. prompt blob
 2. krátké zadání s `Goal`, `Context`, `Constraints`, `Done When`
 
-Nenechte to sklouznout do debaty o tom, který model je chytřejší.
+Nenechte to sklouznout do debaty o tom, který model je chytřejší.
 
 Pointa:
 
@@ -111,94 +113,142 @@ Pointa:
 Na konci talku má být jasné:
 
 - teorie tím končí
-- tým se vrací k repu
-- nejdřív vzniká mapa a první explicitní check
+- tým se vrací k repu
+- pokud tým ještě nemá workshop skill, teď je chvíle na `harness skill install`, pak `Codex: $workshop setup` nebo `pi: /skill:workshop`
+- nejdřív vzniká mapa a první explicitní ověření
 - teprve potom dává smysl další feature motion
 
 ## Build fáze 1
 
 ### Viditelný milestone board
 
-1. do 10:50 existuje repo
-2. do 11:15 existuje `AGENTS.md`
-3. do 11:30 existuje plan
-4. do 11:45 existuje build/test command nebo tracer bullet
-5. do 12:00 existuje první ověřený výstup
+Do oběda má být v repu vidět pět základních věcí:
+
+1. `README`, které dává smysl cizímu člověku
+2. `AGENTS.md` jako krátká mapa
+3. plán, ze kterého je poznat další bezpečný krok
+4. build/test command nebo tracer bullet
+5. první opravdu ověřený posun
 
 ### Role facilitátora
 
-- nejdřív coach — ptejte se, co tým potřebuje a kde je zaseknutý
-- pak mentor — pomozte s workflow nebo s nástrojem
-- učitel až jako poslední možnost — krátce vysvětlete princip a vraťte tým do práce
+- nejdřív coach — ptejte se, co tým potřebuje a kde je zaseknutý
+- pak mentor — pomozte s workflow nebo s nástrojem
+- učitel až jako poslední možnost — krátce vysvětlete princip a vraťte tým do práce
 - vracejte týmům hlavně artefakty, ze kterých se dá opravdu pracovat, ne celý backstage Harness Lab
+- když se tým zasekne, vraťte ho k ověření, ne k delšímu promptu
 
 ### Na co se při obcházení dívat
 
-- Má tým jednu společnou představu o cíli?
-- Přibývá kontext v repu, nebo zůstává jen v chatu a v hlavách?
+- Má tým jednu společnou představu o cíli?
+- Přibývá kontext v repu, nebo zůstává jen v chatu a v hlavách?
 - Ověřují si výstupy, nebo jen generují další text?
-- Mají test, tracer bullet nebo jiné explicitní ověření, které drží agenta v mezích?
-- Je z repa poznat, co je hotové, co je rozpracované a co je jen hypotéza?
+- Mají test, tracer bullet nebo jiné explicitní ověření, které drží agenta v mezích?
+- Je z repa poznat, co je hotové, co je rozpracované a co je jen hypotéza?
 - Uměl by jiný tým během pěti minut najít první bezpečný krok?
 
-### Facilitační pointa k testům
+### Facilitační pointa k testům
 
-- S coding agentem nestačí říct „tohle si pak projdeme“.
+- S coding agentem nestačí říct „tohle si pak projdeme“.
 - Jakmile agent dostává větší autonomii, tým musí zvýšit kvalitu ověřování.
 - Test-first přístup není dogma pro čistotu. Je to praktický způsob, jak převést záměr do formy, kterou agent umí opakovaně trefovat.
 - Když tým žádné ověření nemá, facilitátor má tlačit na nejmenší možný test nebo tracer bullet, ne na další generování funkcí.
-- U UI práce připomínejte pattern: rychlá agent exploration v izolovaném prostředí, potom browser test, potom lidské review.
-- Pokud tým mluví o tom, že „agent to prostě nakliká v mém browseru“, vraťte debatu k sandboxu, nízkému riziku a explicitní kontrole.
+- U UI práce připomínejte pattern: rychlá agent exploration v izolovaném prostředí, potom browser test, potom lidské review.
+- Pokud tým mluví o tom, že „agent to prostě nakliká v mém browseru“, vraťte debatu k sandboxu, nízkému riziku a explicitní kontrole.
 
 ### Co normalizovat
 
 - `AGENTS.md` jako krátkou mapu, ne rostoucí skladiště všeho
-- plan jako pracovní artefakt, ne ceremonii navíc
+- plán jako pracovní artefakt, ne ceremonii navíc
 - malý průběžný úklid, když se začne šířit chaos nebo duplicity
 - převod opakovaných připomínek do repa místo dalšího ústního mentoringu
 
+## Codex demo
+
+### Cíl
+
+Ukázat Codex jako součást pracovního systému, ne jako samostatné kouzlo. Demo má vysvětlit i to, proč tenhle repo drží pohromadě: protože v repu žije záměr, mantinely, rozpad práce do kroků i způsob kontroly, ne jen v hlavě facilitátora.
+
+### Co má být vidět
+
+- jedna příběhová linka, ne přehlídka funkcí
+- repozitář, ve kterém je vidět `README`, `AGENTS.md`, rozpad práce do kroků a způsob, jak změnu zkontrolujete
+- kontrast mezi slabým startem bez kontextu a prací, která má mapu a další bezpečný krok
+- krátké ukotvení workshop skillu: `harness skill install`, první command a proč to šetří ústní rescue
+
+### Co explicitně říct
+
+- „Tohle není demo pro demo. Tohle je způsob, jak vznikal i tenhle workshopový repo systém.“
+- „Když z repa není poznat, proč se změna dělá, jaký je další krok a podle čeho ji zkontrolujete, další člověk ani další agent nenaváže bezpečně.“
+- „Codex je v tomhle důležitý, ale není to pointa sám o sobě. Pointa je harness kolem něj.“
+
+### Co neukazovat
+
+- pět různých módů Codexu za sebou
+- dlouhé čekání na generování bez komentáře
+- repo, které není continuation-ready a slouží jen jako jednorázový sandbox
+
 ## Intermezza
 
 Každé intermezzo má tři kroky:
 
-1. Týmy napíšou jednu větu: „Co jsme změnili a proč.“
-2. Ondřej shrne, co vidí u stolů a co ukazuje monitoring.
-3. Zazní jedna principová pointa navázaná na to, co se opravdu děje v místnosti.
+1. Týmy napíšou jednu větu: „Co jsme změnili a proč.“
+2. Ondřej shrne, co vidí u stolů a co ukazuje monitoring.
+3. Zazní jedna principová pointa navázaná na to, co se opravdu děje v místnosti.
 
 Preferované checkpoint otázky:
 
-- Co jste přesunuli z chatu nebo z hlavy do repa?
-- Co dnes ověřujete pomocí spustitelného checku?
+- Co jste přesunuli z chatu nebo z hlavy do repa?
+- Co dnes ověřujete pomocí spustitelného ověření?
 - Co by měl číst další tým jako první?
 
 ### Smysl intermezz
 
 - zviditelnit učení napříč týmy
-- udělat z průběhu dne sérii krátkých checkpointů
+- udělat z průběhu dne sérii krátkých checkpointů
 - připomenout, že workflow je stejně důležité jako samotný výsledek
-- vracet týmy k tomu, že bez ověření jen akcelerují nejistotu
+- vracet týmy k tomu, že bez ověření jen akcelerují nejistotu
+
+Nevést intermezzo jako status meeting.
+Vést ho jako krátký checkpoint, ze kterého si týmy odnesou jednu věc, kterou ještě ten den dopíšou, zpřesní nebo ověří.
+
+## Oběd a příprava na handoff
+
+- Oběd není pauza od handoffu.
+- Než týmy vstanou od stolu, musí být z repa poznat:
+  - co se změnilo
+  - co je hotové
+  - co je stále hypotéza
+  - jaký je další bezpečný krok
+- Když něco z toho zůstane jen v hovoru, odpoledne se to vrátí jako tření.
 
 ## Rotace
 
 - Bez ústního handoffu.
-- Prvních 10 minut nový tým jen čte repo a mapuje situaci.
-- Frustrace není chyba workshopu. Je to signál kvality kontextu v repozitáři.
+- Prvních 10 minut nový tým jen čte repo a mapuje situaci.
+- Frustrace není chyba workshopu. Je to signál kvality kontextu v repozitáři.
 
 ### Instrukce pro nový tým
 
-- Začněte `README`, `AGENTS.md` a planem.
+- Začněte `README`, `AGENTS.md` a planem.
 - Needitujte hned první soubor, který otevřete.
 - Nejprve si udělejte mapu: co funguje, co chybí, co je rizikové.
-- Nejdřív napište vlastní diagnózu: co pomáhá, co chybí, co je rizikové a jaký je další bezpečný krok.
-- Když tým neví, po čem sáhnout, vraťte ho k learner kitu: `template-agents`, `reference`, `analyze-checklist` a challenge cards.
+- Nejdřív napište vlastní diagnózu: co pomáhá, co chybí, co je rizikové a jaký je další bezpečný krok.
+- Když tým neví, po čem sáhnout, vraťte ho k learner kitu: `template-agents`, `reference`, `analyze-checklist` a challenge cards.
 
-### Facilitační pointa k rotaci
+### Facilitační pointa k rotaci
 
 - Frustrace je užitečný signál, pokud ukazuje na skrytý kontext nebo chybějící verifikaci.
-- Nepomáhejte týmům ústním handoffem nahrazovat slabý signál v repu.
+- Nepomáhejte týmům ústním handoffem nahrazovat slabý signál v repu.
 - Pomáhejte jim pojmenovat, co musí být po rotaci dopsáno, zpřesněno nebo ověřeno.
 
-## Reveal a reflexe
+## Build fáze 2
+
+- Po rotaci neopravujeme jen feature. Opravujeme i signál, který převzetí zbrzdil.
+- Každá opakující se bolest je kandidát na lepší mapu, pravidlo, runbook nebo ověření.
+- Další větší změna má přijít až po nové explicitní verifikaci.
+
+## Reveal a reflexe
 
 ### `1-2-4-All`
 
@@ -206,17 +256,37 @@ Otázky:
 
 - Co vám pomohlo pokračovat?
 - Co chybělo?
-- Jaký signál v repu vám nejvíc ušetřil čas?
+- Jaký signál v repu vám nejvíc ušetřil čas?
 
 ### `W³`
 
 - `Co?` — co se dnes stalo bez hodnocení
-- `A co?` — co to znamená pro práci s AI agenty
+- `A co?` — co to znamená pro práci s AI agenty
 - `A teď?` — co uděláte jinak příští týden
 
 ### Rámec pro facilitaci
 
 - Nehodnotíme, který tým byl lepší.
-- Díváme se na systém: které signály pomáhají práci přežít handoff a které ji brzdí.
+- Díváme se na systém: které signály pomáhají práci přežít handoff a které ji brzdí.
 - Sbíráme konkrétní příklady, ne obecné dojmy.
-- Každá opakující se bolest je kandidát na lepší template, challenge card nebo vodítko v blueprintu.
+- Každá opakující se bolest je kandidát na lepší template, challenge card nebo vodítko v blueprintu.
+
+Na konci dne chceme, aby si lidé odnesli tři věci:
+
+1. jeden signál, který chtějí zavést natrvalo
+2. jednu slabinu, kterou už příště nenechají jen v hovoru
+3. jeden konkrétní tah pro příští týden
+
+### `Monday commitments` — sdílený artefakt
+
+Reflexe bez zápisu se do pondělí většinou neudrží. Proto na samém konci dne:
+
+- každý účastník napíše jednu větu ve tvaru: **„Příští týden udělám [X], protože [důvod z dnešního dne]."**
+- věty se napíší na papírek, sticky note nebo přímo do sdíleného dokumentu
+- facilitátor je sesbírá a udělá z nich jeden krátký sdílený seznam, který si tým odnese
+- seznam není hodnocení ani soutěž. Je to jediný artefakt z dnešního dne, který prokáže, že reflexe skutečně něco změnila
+
+Facilitátorův tah:
+- věty vybízejte k tomu, aby byly konkrétní (ne „budu lépe pracovat s agenty“, ale „do AGENTS.md svého hlavního repa napíšu 4 elementy: goal, context, constraints, done when“)
+- když někdo napíše něco velmi obecného, zeptejte se: „Jaký je první konkrétní tah, který to spustí?"
+- commitmenty nepublikujte jmenovitě mimo room; artefakt patří týmu, ne marketingu

package/assets/workshop-bundle/content/project-briefs/code-review-helper.md

@@ -2,30 +2,30 @@
 
 ## Problém
 
-Code review bývá nevyrovnané. Některé změny projdou s dobrým checklistem a jasným popisem rizik, jiné bez společného rámce. Reviewer pak improvizuje, autor neví, co má ověřit předem, a tým ztrácí konzistenci právě tam, kde by měl být nejpřesnější.
+Code review bývá nevyrovnané. Některé změny projdou s dobrým checklistem a jasným popisem rizik, jiné bez společného rámce. Reviewer pak improvizuje, autor neví, co má ověřit předem, a tým ztrácí konzistenci právě tam, kde by měl být nejpřesnější.
 
-Vaším úkolem je navrhnout nástroj, který z diffu nebo změny vytvoří použitelný review checklist a zároveň jasně oddělí jistotu, heuristiku a místa, kde je pořád potřeba lidský úsudek.
+Vaším úkolem je navrhnout nástroj, který z diffu nebo změny vytvoří použitelný review checklist a zároveň jasně oddělí jistotu, heuristiku a místa, kde je pořád potřeba lidský úsudek.
 
 ## User stories
 
-- Jako reviewer chci z diffu rychle získat checklist změněných hranic, rizik, otázek a míst, na která se zaměřit.
+- Jako reviewer chci z diffu rychle získat checklist změněných hranic, rizik, otázek a míst, na která se zaměřit.
 - Jako autor změny chci vědět, co mám ověřit ještě před samotným review.
 - Jako tým po rotaci chci navázat na heuristiky, které původní tým objevil, místo abych je znovu vymýšlel.
 
 ## Architektonické poznámky
 
-- Může jít o CLI, web nebo jednoduchý skript. Důležitý je jasný tok `diff → rubric → checklist`.
-- Musí být zřejmé, jaké vstupy nástroj očekává, co umí označit jistě a co naopak zůstává heuristické.
-- Přidejte seed diff nebo `examples/`, aby šlo workflow lokálně ověřit a další tým rychle přidal nové pravidlo.
+- Může jít o CLI, web nebo jednoduchý skript. Důležitý je jasný tok `diff → rubric → checklist`.
+- Musí být zřejmé, jaké vstupy nástroj očekává, co umí označit jistě a co naopak zůstává heuristické.
+- Přidejte seed diff nebo `examples/`, aby šlo workflow lokálně ověřit a další tým rychle přidal nové pravidlo.
 - Nástroj má pomáhat reviewerovi, ne předstírat neomylnost.
 
 ## Hotovo když
 
 - Nástroj vytvoří review checklist ze seed diffu.
-- Výstup odlišuje jistá zjištění od doporučení, hypotéz a bodů pro lidský úsudek.
+- Výstup odlišuje jistá zjištění od doporučení, hypotéz a bodů pro lidský úsudek.
 - Je jasné, jak přidat nové pravidlo nebo heuristiku bez dlouhého onboardingu.
-- Další tým může během několika minut pokračovat v rozvoji bez chaosu.
+- Další tým může během několika minut pokračovat v rozvoji bez chaosu.
 
 ## První krok pro agenta
 
-Nezačínej kódem. Nejdřív napiš review rubric, tok vstupů a definici toho, co znamená dobrý checklist. Ukaž, kde je jistota, kde heuristika a co musí posoudit člověk. Teprve potom navrhni první implementační slice.
+Nezačínej kódem. Nejdřív napiš review rubric, tok vstupů a definici toho, co znamená dobrý checklist. Ukaž, kde je jistota, kde heuristika a co musí posoudit člověk. Teprve potom navrhni první implementační slice.