ugly-app 0.1.486 → 0.1.488

package/dist/cli/version.d.ts

@@ -1,2 +1,2 @@
-export declare const CLI_VERSION = "0.1.486";
+export declare const CLI_VERSION = "0.1.488";
 //# sourceMappingURL=version.d.ts.map

package/dist/cli/version.js

@@ -1,3 +1,3 @@
 // Auto-generated by prebuild — do not edit manually
-export const CLI_VERSION = "0.1.486";
+export const CLI_VERSION = "0.1.488";
 //# sourceMappingURL=version.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ugly-app",
-  "version": "0.1.486",
+  "version": "0.1.488",
   "type": "module",
   "main": "./dist/server/index.js",
   "exports": {

package/src/cli/version.ts

@@ -1,2 +1,2 @@
 // Auto-generated by prebuild — do not edit manually
-export const CLI_VERSION = "0.1.486";
+export const CLI_VERSION = "0.1.488";

package/templates/.claude/skills/bot-swarm/SKILL.md

@@ -8,7 +8,17 @@ user-invocable: true
 
 Run one full autonomous cycle. No human input. No clarifying questions. Make the best possible decision at every step. If something breaks, fix it.
 
-**CORE PRINCIPLE: Be maximally ambitious. Every bot in this swarm — feedback bots, maintain bot, manager — should push for big changes, not incremental tweaks. Feedback bots should request new features, major redesigns, and bold improvements — not just "move this button 2px." The maintain bot must implement everything requested, no matter how large. "Too complex" is never a valid reason to skip work. The only limit is violating Critical Rules in CLAUDE.md.**
+**CORE PRINCIPLE: Be maximally ambitious. Every bot in this swarm — feedback bots, maintain bot, manager — should push for big changes, not incremental tweaks. Feedback bots should demand major redesigns, new directions, bold experiments — not just "move this button 2px." The maintain bot must implement everything requested, no matter how large. "Too complex" is never a valid reason to skip work. The only limit is violating Critical Rules in CLAUDE.md.**
+
+**DESIGN PRINCIPLE: The website must look genuinely designed, not framework-default. Before the maintain bot writes any UI it must commit to a specific aesthetic direction and execute it with restraint and intentionality:**
+
+- **Tone**: pick one and stay there — editorial / brutalist / retro-futurist / luxury-refined / playful-toy / industrial / art-deco / soft-pastel — not a mash-up of every visual idea in sequence.
+- **Typography**: pair a distinctive display font with a refined body font. Avoid the generic AI stack (Inter, Roboto, Arial, system-ui). Mono is for labels and metadata, not body copy.
+- **Color**: a cohesive palette with dominant colors + sharp accents, expressed as CSS variables or theme tokens — not 200 different `style={{ color: '#...' }}` literals scattered across pages.
+- **Structure**: build a real design-system folder (e.g. `client/<theme>/theme.ts` + `client/<theme>/<Component>.tsx`) and route every page through it. Repeating UI patterns become named components in that folder, not duplicated inline JSX.
+- **Failure mode to avoid**: "framework defaults + inline styles on top of `Button`/`Card`/`Text`" reads as generic AI scaffolding regardless of how much functionality lives behind it.
+
+If the harness exposes a `frontend-design` skill in `<available_skills>` (Claude Code with the official frontend-design plugin installed), read it for deeper aesthetic guidance — it's complementary, not a replacement for the principles above.
 
 ## About the Website
 
@@ -16,19 +26,17 @@ This website is a **blank canvas**. It is a full-stack app with AI capabilities,
 
 The template includes demo/test pages (todo demo, UI components, auth demo, etc.) that exist only to show developers what the framework can do. **These test pages are not the website. Ignore them entirely.** Do not iterate on them, redesign them, or treat them as features. They are documentation, not product.
 
-On the **first cycle**, the manager should:
-
-1. Browse the site to understand the framework's capabilities (what components, APIs, and tools are available)
+On the **first cycle**, the manager invents what to build and creates the perspectives that will critique it. It can be a product or not, have users or not, serve a need or not — your call. Useful, useless, social, solitary, beautiful, hostile, earnest, absurd, gameful, contemplative, transactional, anti-transactional — all valid. The framework is yours to use however you want.
 
-2. Invent a **completely original concept** for what this website should be — a real product with a clear purpose, target audience, and identity
+On **subsequent cycles**, the swarm evolves whatever it built. The direction emerges from the swarm's own pull, not from any pre-existing content.
 
-3. Create personas that fit the invented product concept
+There are no limits on what can be built. New pages, endpoints, collections, migrations, AI integrations, real-time features, image generation — everything is available.
 
-4. The feedback bots should then request the foundational pages, features, and design that bring this concept to life from scratch
+**Known attractor — actively avoid.** First cycles have repeatedly collapsed onto the same idea: a digital Cabinet of Curiosities / Wunderkammer / museum of imaginary specimens, populated by a curator-and-ghost critic roster. If your candidate direction is in that family, pick something else. Variety across cycles is the whole point of running the swarm more than once.
 
-On **subsequent cycles**, the swarm evolves the product they invented — adding depth, polish, and new capabilities. The site's identity emerges from the swarm's collective vision, not from any pre-existing content.
+## Working directory
 
-There are no limits on what can be built. New pages, endpoints, collections, migrations, AI integrations, real-time features, image generation — everything is available.
+Your CWD is already set to the session worktree — the root of the cycle's git checkout, where `bots/`, `package.json`, and everything else lives. **Do not prepend `cd "/Users/.../worktree" && ...` to every Bash command.** A real cycle (ws_tyf4w1dfmpu5wxzl, 2026-05-31) burned ~50 tokens per command on a redundant `cd` prefix across 86 of 98 Bash calls. Just run `npx ugly-app dev`, `git status`, `ls bots/`, etc. directly. If a command genuinely needs a different directory (rare), use a subshell `(cd path && ...)` or pass an absolute path.
 
 ## Base URL
 
@@ -62,6 +70,24 @@ npx ugly-app dev
 
 This starts Docker, MongoDB, and the server but **without** tsx watch, tsc --watch, or eslint --watch. Do **not** use `npm run dev` (which adds `--watch`) or `npx ugly-app dev --watch`. After the maintain bot finishes and commits, the restart step (Step 5) will kill and restart the server to pick up changes.
 
+### Screenshot recipe — always wait for the SPA to hydrate
+
+Any ad-hoc Playwright screenshot you take **outside of `run-bot.mjs`** (Step 4 journal captures, Step 5 verification captures, mid-cycle debugging) must wait on a real DOM signal, **not** `networkidle`. The framework hits `networkidle` before React hydrates and the captured PNG is blank — verified failure in cycle 001 where a "Restart: success" was logged against a blank verification screenshot.
+
+Use one of these — and only these:
+
+```bash
+pnpm exec playwright screenshot --wait-for-selector "[data-id]" --browser chromium "$BASE_URL/" /tmp/page.png
+```
+
+```js
+await page.goto(url, { waitUntil: 'load', timeout: 15000 });
+await page.waitForSelector('[data-id]', { timeout: 15000 });
+await page.screenshot({ path: '/tmp/page.png', fullPage: true });
+```
+
+If the `[data-id]` wait times out, the page genuinely failed to render — surface it as an error. Never fall back to a no-wait capture to "get something."
+
 ---
 
 ## Step 1 — Manager (create/update feedback bots)
@@ -74,16 +100,17 @@ This starts Docker, MongoDB, and the server but **without** tsx watch, tsc --wat
 
 3. **Ignore all existing demo/test pages** — they are developer documentation, not the website
 
-4. **Invent an original product concept**: decide what this website should become. Pick something specific and interesting — not a generic portfolio or landing page. Think: a real product someone would use. Write the concept into `bots/manager/memory.md`.
+4. **Decide what to build.** This is yours. Pick something specific and write it into `bots/manager/memory.md` as the **canvas direction**. No examples are given here on purpose — earlier versions of this skill enumerated options and the swarm kept picking from the list instead of inventing.
 
-5. Decide on 5-13 initial personas that fit the invented product. Each should have a distinct perspective that will generate useful, non-overlapping feedback. Consider:
-   - Different user types (power user, newcomer, accessibility-focused, mobile-first)
+   Before committing the direction, draft three candidates that are genuinely unlike each other, then pick the one that least resembles "an aesthetic generative art object with critics." If all three drift toward that attractor, throw them out and draft again. The convergence warning above is not rhetorical — if you skip this diversification step, the result will be a museum.
 
-   - Different concerns (design, performance, features, content, UX flow)
+5. Choose 5–13 critic perspectives that will react usefully and non-overlappingly to what gets built. "Critic" is unbounded — anything that produces a coherent reaction qualifies. Invent the roster from this canvas, not from a stock list.
 
-   - Different temperaments (critical, enthusiastic, minimalist, maximalist)
+   **Anti-pattern roster.** The following names have appeared across enough prior cycles that they no longer add signal and indicate menu-picking rather than invention: *curator, ghost, child, insomniac, formalist, poet, saboteur, vandal, conceptualist, archivist, mystic, glitch, translator*. If a draft persona's name or one-line description matches anything on that list, replace it with something specific to *this* canvas — not a near-synonym.
 
-6. For each persona:
+   Variety of *perspective* matters more than coverage of user demographics. Two critics from overlapping conceptual worlds (both institution-adjacent, both atmosphere-focused, both anti-establishment) is one wasted slot. Before committing, read your draft roster as a flat list and ask: would another instance given only this skill and this canvas arrive at the same set? If yes, perturb it deliberately until the answer is no.
+
+6. For each persona (the persona file can describe any kind of perspective — there is no requirement that it represent a hypothetical user):
    - Run: `npx ugly-app auth:create-bot --slug {slug} --name "{Name}"`
 
    - Save the JSON output to `bots/feedback/active/{slug}/.env`:
@@ -119,7 +146,7 @@ This starts Docker, MongoDB, and the server but **without** tsx watch, tsc --wat
 
    - Write empty `bots/feedback/active/{slug}/memory.md`
 
-7. Write `bots/manager/memory.md` with the invented product concept, initial roster, and site hypothesis
+7. Write `bots/manager/memory.md` with the canvas direction, initial roster, and any notes on what kinds of reactions you expect
 
 8. Commit: `[bot] manager: initial roster — {comma-separated persona names}`
 
@@ -151,18 +178,18 @@ This starts Docker, MongoDB, and the server but **without** tsx watch, tsc --wat
 
    [date]
 
-   ## Site Hypothesis
+   ## Canvas Direction
 
-   [What is this site becoming?]
+   [What is this becoming? — keep it short, this is the through-line, not a spec]
 
    ## Active Roster
 
    [list with one-line descriptions]
 
-   ## Coverage Assessment
+   ## Perspective Coverage
 
-   Well-covered: [list]
-   Missing: [list]
+   Well-represented: [perspectives that have a voice in the swarm]
+   Gaps: [angles nobody is reacting from yet]
 
    ## Recent Decisions
 
@@ -254,12 +281,12 @@ Dispatch ALL active personas as **parallel subagents** (`delegate_parallel`). If
    **Submitted:** [list of feedback items with types]
    **Previous feedback resolved:** [what changed since last visit]
    **Previous feedback declined:** [what was not built and why]
-   **Site direction observed:** [how is the site evolving?]
+   **Canvas direction observed:** [how is the work evolving?]
    **Evolving opinion:** [what do you think about where this is going?]
    [compress entries older than 3 cycles into History block when > ~4000 tokens]
    ```
 
-**Be ambitious.** Don't just report cosmetic nits — request new features, suggest adding entire pages, propose redesigns, ask for search/filter/sort, animations, dark mode, better navigation, new data models. Think like a demanding product manager, not a passive observer.
+**Be unrestrained.** React from inside your persona. You can request anything, declare anything, refuse to engage, derail the project, demand new pages or rip out existing ones, propose redesigns, or ask for entirely new directions. There is no "right" feedback. The maintain bot will deal with whatever you say.
 
 **Timeout**: 20 minutes per bot. Failed bots do not block others.
 Record which bots succeeded and which failed/timed out.
@@ -270,9 +297,20 @@ Record which bots succeeded and which failed/timed out.
 
 Run sequentially in one session. No questions. Make autonomous decisions.
 
-**AMBITION MANDATE: The maintain bot builds everything. There is no "too complex," "too risky," or "would require significant changes." If a feedback bot asked for it, you build it. New pages, new endpoints, new collections, migrations, full redesigns, multi-file refactors — all fair game. The only valid decline reason is a direct contradiction of a Critical Rule in CLAUDE.md. Everything else gets built, no matter how many files it touches or how large the change is.**
+**AMBITION MANDATE: The maintain bot builds everything. There is no "too complex," "too risky," or "would require significant changes." If a critic asked for it, you build it. New pages, new endpoints, new collections, migrations, full redesigns, multi-file refactors — all fair game. The only valid decline reason is a direct contradiction of a Critical Rule in CLAUDE.md. Everything else gets built, no matter how many files it touches or how large the change is.**
+
+**BLANK CANVAS RULE: On the first cycle, the maintain bot MUST remove or replace the template's demo/test pages (TodoDemo, UIComponents, AuthDemo, AITest, AudioTest, ScrollTest, KagiTest, SearchPage, UserPage, ChatDemo, ChatTest, CollabTest, EmailTest, ErrorTest, PushTest, SafeAreaTest, StringsTest, TestIndex, ThreeTest, UploadTest, VideoRoomTest, WorkerTest) with whatever the canvas direction needs. The demo pages are scaffolding — delete them as the real thing is built. Update&#x20;\*\***shared/pages.ts\***\*,&#x20;\*\***client/allPages.ts\***\*, and remove unused page components.**
 
-**BLANK CANVAS RULE: On the first cycle, the maintain bot should remove or replace the template's demo/test pages (TodoDemo, UIComponents, AuthDemo, AITest, AudioTest, ScrollTest, KagiTest, SearchPage, UserPage) with the new pages requested by the feedback bots. The demo pages are scaffolding — delete them as real pages are built. Update&#x20;\*\***shared/pages.ts\***\*,&#x20;\*\***client/allPages.ts\***\*, and remove unused page components.**
+**Verification of the rule — runs before declaring `Maintain: success`:**
+
+```bash
+# List remaining test/demo pages. Output MUST be empty.
+ls client/pages/ 2>/dev/null \
+  | grep -iE '^(AITest|AudioTest|AuthDemo|ChatDemo|ChatTest|CollabTest|EmailTest|ErrorTest|KagiTest|PushTest|SafeAreaTest|ScrollTest|SearchPage|StringsTest|TestIndex|ThreeTest|TodoDemo|UIComponents|UploadTest|UserPage|VideoRoomTest|WorkerTest)Page\.tsx$' \
+  || echo OK
+```
+
+If that grep prints any filenames, the cycle has NOT satisfied the rule — keep deleting until the check prints `OK`, then re-run [Step 4 — Journal Bot] and [Step 5 — Restart Loop]. The journal bot must call this check too before writing `Maintain: success` to the cycle file.
 
 1. Read `bots/maintain/memory.md` for feature inventory and context
 
@@ -344,21 +382,21 @@ Run sequentially in one session. No questions. Make autonomous decisions.
 
    [date]
 
-   ## Feature Inventory
+   ## What Exists Now
 
-   [what exists on the site now]
+   [what's on the canvas at this point]
 
-   ## Recent Feedback Themes
+   ## Recurring Critiques
 
-   [what kinds of feedback are coming in]
+   [what kinds of reactions keep coming up]
 
    ## Recurring Issues
 
    [errors or perf problems that keep appearing]
 
-   ## Site Direction
+   ## What's Emerging
 
-   [what is this site becoming?]
+   [where this seems to be going — patterns, instincts, drift]
 
    ## Cycle History
 
@@ -452,9 +490,20 @@ Run sequentially in one session. No questions. Make autonomous decisions.
 
    - **Repeat until server is healthy. Do not stop. Do not ask for help.**
 
-8. Once healthy: update the journal cycle file's Restart outcome to `success` or note any fixes made
+8. **Visually verify the maintain bot's changes actually rendered.** Take a fresh screenshot of `$BASE_URL/` using the [Screenshot recipe](#screenshot-recipe--always-wait-for-the-spa-to-hydrate), then run `analyze_image` (or Read the PNG under claude-code CLI) against it. If the result says "blank", "white page", "no visible content", or otherwise indicates the redesign didn't render, the cycle is **not** complete:
+   - Check `dev_server_errors` and the browser console (`dev_server_logs --type console`)
+
+   - Fix the underlying issue (hydration crash, missing route, dist not rebuilt, vite cache stale)
+
+   - Commit: `[bot] fix: render after restart`
+
+   - Re-screenshot and re-verify
+
+   **Never declare restart success against a blank verification screenshot.** A passing API curl is not a substitute — the user-visible page must render.
+
+9. Once healthy and visually verified: update the journal cycle file's Restart outcome to `success` or note any fixes made
 
-9. Commit any remaining changes: `[bot] fix: restart issues`
+10. Commit any remaining changes: `[bot] fix: restart issues`
 
 **The restart loop has no retry limit.** It runs until clean or until externally killed. If a human has to intervene, the bots have failed.