ugly-app 0.1.145 → 0.1.146

package/dist/cli/version.d.ts

@@ -1,2 +1,2 @@
-export declare const CLI_VERSION = "0.1.145";
+export declare const CLI_VERSION = "0.1.146";
 //# 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.145";
+export const CLI_VERSION = "0.1.146";
 //# sourceMappingURL=version.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ugly-app",
-  "version": "0.1.145",
+  "version": "0.1.146",
   "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.145";
+export const CLI_VERSION = "0.1.146";

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

@@ -8,6 +8,8 @@ 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.**
+
 ## Prerequisites
 
 - `npm run dev` must be running (Docker, server, Vite)
@@ -146,6 +148,8 @@ Dispatch ALL active personas as **parallel subagents**. Each subagent does:
          }
        }'
      ```
+**Feedback bots should be ambitious in what they request.** Don't just report cosmetic nits — request new features, suggest adding entire new pages, propose redesigns, ask for search/filter/sort capabilities, request animations, dark mode, better navigation, new data models. Think like a demanding product manager, not a passive observer. The feedback should push the site to evolve rapidly.
+
 8. Update `bots/feedback/active/{slug}/memory.md`:
    ```markdown
    ## Cycle [YYYY-MM-DD]
@@ -166,6 +170,8 @@ 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.**
+
 1. Read `bots/maintain/memory.md` for feature inventory and context
 2. Mark all `new` feedback as `captured` to prevent double-processing:
    - Run `npm run feedback --json` to get all feedback
@@ -178,8 +184,14 @@ Run sequentially in one session. No questions. Make autonomous decisions.
      ```
 3. Invoke `/fix-feedback local` — run completely unattended:
    - Do not ask which environment. Use `local`.
-   - For each feedback item: implement the fix or feature. Build it, no matter how large.
-   - Resolve each item via API with status `resolved` or `declined` and a resolution message.
+   - For each feedback item: implement the fix or feature. **Build it, no matter how large.**
+   - **Never decline feedback because it's "complex" or "ambitious."** If you're unsure how, read existing code and the ugly-app API reference, then figure it out.
+   - If feedback requires new pages: add routes in `shared/pages.ts`, components in `client/pages/`, mappings in `client/allPages.ts`.
+   - If feedback requires new endpoints: add to `shared/api.ts` and `server/index.ts`.
+   - If feedback requires new collections: add to `shared/collections.ts`, run `npm run db:init`.
+   - If feedback requires images: use `npm run imageGen -- "prompt" --output client/assets/<name>.png`.
+   - If feedback requires schema changes: write a migration in `server/migrations/`.
+   - Resolve each item via API with status `resolved` (preferred) or `declined` (only for Critical Rule violations) and a resolution message.
    - Commit each change: `[bot] fix: ...` or `[bot] feat: ...`
 4. Invoke `/fix-code` — run completely unattended:
    - Fix all TypeScript errors, lint warnings, test failures.

package/templates/.claude/skills/fix-feedback/SKILL.md

@@ -18,5 +18,20 @@ Run: `npm run feedback:server`
 
 This fetches recent user feedback from MongoDB. For each piece of feedback:
 1. Understand the user's issue or request
-2. Implement the fix or feature
+2. Implement the fix or feature — **no matter how large or complex**
 3. Run `npm run build` to verify it compiles
+
+## Ambition policy
+
+**You must attempt every piece of feedback.** There is no such thing as "too complex" or "too risky" or "out of scope." If a user asked for it, build it. This includes:
+
+- New pages, new collections, new API endpoints
+- Major UI redesigns or layout overhauls
+- Adding entirely new features (search, filtering, sorting, animations, themes)
+- Generating images with `npm run imageGen` when visuals are needed
+- Writing migrations when collection schemas must change
+- Multi-file changes that touch client, server, and shared simultaneously
+
+The only valid reason to decline feedback is if it contradicts a Critical Rule in CLAUDE.md (e.g. "commit .env" or "add `any` types"). Everything else gets built.
+
+If you're unsure how to implement something, read the existing code, read the ugly-app API reference, and figure it out. Do not skip it. Do not defer it. Do not say "this would require significant refactoring" — just do the refactoring.