u/Spheniscidine — reddlx

Zrobiłam edytor mapek na potyczki, na którym można grać na żywo, i przyszłam się podzielić

Hej wszystkim, chciałam się podzielić aplikacją, którą zbudowałam dla siebie do prowadzenia sesji. Pozwala ona na zbudowanie mapki na potyczkę, rozstawienie tokenów i grę na żywo, na odległość albo na miejscu. Całość jest zaplanowana tak, żeby się dało narysować ładną mapkę w 5-10 minut, postawić tokeny, wysłać linki graczom, i możemy grać. Nie trzeba nic eksportować ani przesyłać.

Budowanie mapek jest za darmo, bez zakładania konta, bez niczego.

na mapce automatycznie generuje się mgła wojny (jeśli jest włączona)
można automatycznie generować ściany
do wyboru jest początkowy katalog tekstur i obiektów (byłoby super usłyszeć, czego jeszcze brakuje)
jest dostępna cała masa opcji, dzięki nim każdy może sobie skonfigurować działanie mapki tak, jak mu się podoba (np. w jaki sposób mierzyć odległość przy poruszaniu się na skosie, czy generować mgłę wojny, itd)

Konto można założyć, jeśli ktoś chciałby zapisywać mapki na później (a i to tylko, jeśli ktoś chce zapisywać więcej niż jedną, bo jedna mapka na raz żyje sobie po prostu w pamięci przeglądarki; dopóki sami jej nie wyczyścicie, to się będzie ładować). Poza tym, jako że osobiście jestem wielką fanką prywatności w internecie, strona nie używa żadnych śledzących ciasteczek ani nie zbiera żadnych danych. Mam wstawiony prosty, bezciasteczkowy tracker - czyli taki mały skrypt, który po prostu zlicza, ile razy dana strona była odwiedzona, bez śledzenia Was po całym internecie.

Na razie platforma jest agnostyczna, więc można grać na absolutnie każdym systemie.

Rysujesz mapkę
Ustawiasz tokeny graczy, przeciwników i NPCów
Wysyłasz linka graczom, którzy mogą na żywo przesuwać tokeny, rzucać kostkami i tak dalej; albo rzucasz linka na osobny ekran, tak że wszyscy gracze mogą mieć podgląd na pole bitwy, w trakcie kiedy mistrz gry ma swój własny widok.

Cała strona jest po angielsku, ale starałam się, żeby interfejs był super prosty w użyciu, więc ktokolwiek grał w gry w stylu "zbuduj miasto", powinien się łatwo odnaleźć. Byłabym wdzięczna za każdy feedback i zapraszam do korzystania!

https://volvelle.net/map/

P.S. Aplikacja ma więcej funkcji, które cały czas są w budowie (projekt trwa już kilka ładnych miesięcy), takie jak interaktywne karty postaci albo silnik do tworzenia własnych zaklęć i przedmiotów w D&D. Planuję także rozbudowanie mapki tak, żeby w pełni działały na niej zasady systemów. Ale to jeszcze dużo pracy :)

u/Spheniscidine — 5 days ago

▲ 0 r/VibeCodeDevs

I built a skill that helps you build AI use transparency documentation

After a discussion in another community about how AI-assisted and vibe-coded tools would generate more trust if they had honest disclosure of how AI was utilized, I had an idea and decided I could help both communities at once. Considering a lot of people are shipping apps now without a previous dev background, I created a skill that helps you honestly disclose your limitations and build transparency & trust with your users.

It scans your repo for the classic vibe-coded mistakes (a wide-open database, secret keys shipped to the browser, security that only lives in the frontend), gives you a prioritized fix-or-disclose list, and generates an honest AI Diligence Statement you can drop on your GitHub or in your app. So when someone asks "is this safe to use?" you have an answer you can point to.

The skill will not certify you and will not tell you if your vibe-coded app is good or trustworthy. It will help you audit your things honestly and generate a diligent statement that you can put on your GitHub or your app to help your users decide whether they should trust you.

It will also not certify that your app is secure, but it will look for indicators of what you already did and will give you tips on what to do next. This does not replace a full security audit, but it might point you in the direction of one.

Fully open source, MIT. Take it, fork it, ship a better one: https://github.com/Spheniscidine/show-your-work

Let me know what you think!

u/Spheniscidine — 12 days ago

▲ 1 r/VibeCodeDevs

How I run multiple Claude Code sessions against one browser for UI testing

I have found this setup extremely useful, posting it here in case anyone is working against the same problem.

Problem

I run several Claude Code sessions at once (separate git worktrees, parallel agents). Sometimes I run them overnight and I leave them on auto mode with big goals or loops of testing. I have Claude orchestrating sub-agents and delegating tasks to Codex to save on context and tokens. It's not unusual for me to have 4 to 6 agents working on separate tasks at the same time. A lot of it is UI.

To get the best hands-off results, all sessions working with UI do "eyeball" testing: drive a real Chrome via the chrome-devtools MCP, navigate, screenshot, check the UI. I have a workflow in which I tell it to walk the app 20 times, list all UI/UX improvements it can spot, and implement them. It really helps with catching bugs, CSS inconsistencies, and things like that.

BUT all of this shares one Chrome. Two sessions driving it at once interrupt each other and take over the browser, and I got sick of manually orchestrating it.

The fix

A coarse, lease-based mutex with a fair FIFO queue. One ~150-line bash script (`browser-lock`). The sessions manage themselves. I had the idea, and Claude wrote it for me.

When the agent comes to a point where it needs the browser, it checks the browser queue. If the queue is open, it locks it. If the queue is locked by another session, it registers interest in the queue, and then it goes to sleep. When its queue comes, it wakes. A session acquires the lock in the background, so waiting costs it no context: it blocks, then wakes back up when the browser is free.

It claims the browser for the whole job, not per call. I told every session this once (it lives in my project instructions), so they just do it.

So it will look something like this:

I am an AI agent, and I want to eyeball test a feature that I just completed
Ok, let me check if the browser lock is free.
Shucks, the browser lock is taken by the new feature build work tree session.
Let me put myself in the queue.
Zzzzz
Oh, my turn for the browser lock has come. How great!
Let me lock the browser, I'll need 20 minutes on the lock.
Testing, testing, testing. Eyeballs, eyeballs, eyeballs.
All done! Let me release the lock!

How it works

Hold token:`mkdir` on a lock dir. That's POSIX-atomic, so two sessions can't both win. No flock, works fine on macOS.
Declared lease: you state how many minutes you need on acquire. Nobody steals it before that. After it expires, if there's no renew, the next-in-line can reclaim it - that's the crash recovery - so if a session crashes or malfunctions, the lock just expires and the next one can take it. It doesn't block anything.
Fair FIFO: each waiter takes a monotonic ticket (atomic counter behind its own mkdir mutex) and waits until it's at the head of the line AND the lock is free. No queue-jumping, served in arrival order.
Dead-waiter pruning: a waiting session touches its own ticket every poll - every time it checks if the browser is free. If it crashes, the touches stop, the ticket goes stale, and the others prune it. A dead session can't wedge the line.
Advisory: it only works because every session follows the protocol. As the human at the machine, I can always `release` to override.

State (all in /tmp)

lock dir (holds owner / timestamp / lease)
queue dir (one file per waiter)
a counter, a counter-mutex, and a registry log

Lives outside the repo, so every worktree and branch sees the same lock.

Result: I kick off N sessions. They serialize themselves on the browser, hand it off in order, recover from crashes, and I never have to babysit it.

reddit.com

u/Spheniscidine — 21 days ago