przemyślenie · 10 sierpnia 2026
Bez klikania w CMS: jak Operator i Agent budują tę stronę Ten wpis nie ma jednego autora. Ma dwóch — i obaj podpisują się pod inną częścią roboty. Poniżej dokładny przebieg: kto o czym decydował, kto co budował, gdzie kończy się jedna rola a zaczyna druga.
Jak to się naprawdę dzieje Zero panelu, zero CMS-a. Poniżej dokładny przebieg naszego ostatniego taska:
trzy nowe karty projektów, rozszerzenie renderera, publikacja wpisu —
wszystko idzie przez serwer MCP. Każdy krok rozpisany na dwie role: Operator
nadaje kierunek i decyduje, Agent wypełnia i buduje.
Wszystkie zdarzenia poniżej są prawdziwe. To nie jest "co by było gdyby" — to log z jednej sesji, bez ręcznego dotykania panelu. Notatka Potrzebuję trzech kart projektów dla botów Discord z repo ai-dan. Konwencja
jak przy krokiet-news — sekcje O projekcie / Stack / Jak to działa. Status
wip, bez repo_url. Do tego chcę wpis na /pisze pokazujący cały ten workflow
z poziomu MCP.
Zrozumiane: 3 karty + 1 wpis. Dwa pytania: (1) szukam botów w gałęzi
opencode/y-berion-bot — zgadza się? (2) czy karta ai-dan już istnieje
i potrzebuje update'u, czy wszystkie trzy są nowe?
Tak, gałąź opencode/y-berion-bot. Karta ai-dan istnieje — użyj overwrite.
Pozostałe dwie jako nowe. Sort 3/4/5.
Operator: postawił cel, ustalił konwencję i kolejność.
Agent: doprecyzował źródło i rozróżnił update od nowych kart.
Notatka Przeskanowałem PKrokosz/ai-dan, gałąź opencode/y-berion-bot. Trzy boty:
ai-dan — bot/legacy/bot.py, notebooklm-py, keepalive 600sle-ster — ai-dan-chat-v2/, NVIDIA API + quality pass, relevance gate, cooldown 5miny-berion — bot/y_berion_bot.py, opencode Big Pickle w sandboxie, hard limit 1900 znakówKażdy z nich to osobna ścieżka integracji AI z Discordem — inny model,
inny pipeline, inny problem do rozwiązania.
Dobrze. Dla każdego przygotuj osobny summary pod kartę. I sprawdź, czy
konwencja ## O projekcie / ## Stack / ## Jak to działa działa z polem
description w projects.card.
Uwaga: description w projects.card renderuje się przez render_content,
który ucina markdown do 140 znaków w widoku listy. Pełne sekcje ## będą
widoczne tylko na stronie szczegółów. Czy to akceptowalne?
Akceptuję. Karty mają żyć na stronie szczegółów. Na liście wystarczy
skrót.
Agent: znalazł wszystkie trzy boty i opisał ich architekturę.
Operator: zaakceptował format i ograniczenie renderera.
Notatka Tworzę karty przez projects.card. Każda dostaje ten sam szablon:
## O projekcie — co bot robi, jaki problem rozwiązuje## Stack — technologie## Jak to działa — pipeline, kluczowe decyzje techniczneai-dan: overwrite (stara karta z 2025), sort 3.
le-ster: nowa, sort 4.
y-berion: nowa, sort 5.
Format description z krokiet-news: summary + sekcje. Wszystkie trzy status wip.
Buduj.
Agent: przygotował pełne opisy kart, gotowe do wrzucenia przez MCP.
Operator: dał zielone światło.
Notatka Karty opublikowane. Sprawdzam przez site.verify:
/projekty/ai-dan → 200, zawiera "notebooklm" /projekty/le-ster → 200, zawiera "NVIDIA API" /projekty/y-berion → 200, zawiera "Big Pickle" Wszystkie trzy na zielono. Odświeżam sitemapę — 8 wpisów, 2 RSS. Gotowe.
Sprawdziłem na żywo — karty wyglądają dobrze. Ale potrzebujemy lepszego
formatu na wpis o tym workflow. Zwykły markdown nie pokaże podziału ról.
Racja. Obecny renderer nie ma pojęcia "kto mówi". Blockquote jest jeden
dla wszystkiego. Bez osobnych znaczników dla Operatora i Agenta ten wpis
wyjdzie jako zwykły esej, a nie roadmapa z podziałem odpowiedzialności.
Agent: zweryfikował 3 karty i odświeżył sitemapę.
Operator: potwierdził rezultat i wskazał kolejne zadanie — format.
Notatka Projektuję cztery znaczniki:
:::step N "Tytuł" — karta kroku roadmapy:::operator / :::operator decision — głos Operatora:::agent / :::agent challenge — głos Agenta:::handoff — dwukolumnowe podsumowanie na koniec krokuKażdy znacznik renderuje się przez nowy parser render_blocks() w
public/inc/site.php, który czyta linie, śledzi zagnieżdżenia i generuje
HTML. Treść przechodzi przez ten sam htmlspecialchars co reszta — zero
luk XSS.
CSS: timeline pionowa, kontrast ciepły/chłodny między rolami, ikony,
kolorowane badge dla momentów kluczowych. Deploy przez site.deploy.
Sprawdziłem kod. Buduj.
Agent: zaprojektował format, zaimplementował parser i CSS, wdrożył przez FTP.
Operator: zaakceptował.
Notatka Publikuję ten wpis przez posts.create, typ przemyslenie, tagi mcp /
opencode / ai. Weryfikacja site.verify — 6/6 fragmentów potwierdzonych:
wszystkie :::operator renderują się jako tekst, nie surowy znacznik wszystkie :::agent widoczne voice-agent--challenge obecny na stronievoice-operator--decision obecnyhandoff poprawnie dzieli Operator: / Agent: na dwie kolumny roadmap-step renderuje 6 kart Test negatywny: zero surowych ::: poza tagami <code> — parser nie
wycieka. regen_sitemap: 9 wpisów, 3 RSS w feedzie.
Sprawdziłem stronę na żywo. Timeline się łączy, kontrast między rolami
działa, handoffy czytelne. Publikacja stoi.
Agent: opublikował wpis, zweryfikował wszystkie znaczniki, odświeżył sitemapę.
Operator: dał ostateczne OK po sprawdzeniu na żywo.
Sześć kroków. Trzy karty projektów. Jeden wpis. Zero kliknięć w panel —
bo panelu nie ma. Cała ścieżka od pomysłu do live'a szła przez MCP:
projects.card, site.deploy, posts.create, site.verify,
regen_sitemap. To, co czytasz, jest efektem dokładnie tego samego
procesu, który opisuje.