@pugi/cli 1.0.0-alpha.157 → 1.0.0-alpha.159

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pugi/cli",
-  "version": "1.0.0-alpha.157",
+  "version": "1.0.0-alpha.159",
   "description": "Pugi CLI - terminal-native software execution system",
   "license": "MIT",
   "homepage": "https://pugi.io",
@@ -40,11 +40,11 @@
     "LICENSE"
   ],
   "optionalDependencies": {
-    "@pugi/cli-darwin-arm64": "1.0.0-alpha.157",
-    "@pugi/cli-darwin-x64": "1.0.0-alpha.157",
-    "@pugi/cli-linux-arm64": "1.0.0-alpha.157",
-    "@pugi/cli-linux-x64": "1.0.0-alpha.157",
-    "@pugi/cli-windows-arm64": "1.0.0-alpha.157",
-    "@pugi/cli-windows-x64": "1.0.0-alpha.157"
+    "@pugi/cli-darwin-arm64": "1.0.0-alpha.159",
+    "@pugi/cli-darwin-x64": "1.0.0-alpha.159",
+    "@pugi/cli-linux-arm64": "1.0.0-alpha.159",
+    "@pugi/cli-linux-x64": "1.0.0-alpha.159",
+    "@pugi/cli-windows-arm64": "1.0.0-alpha.159",
+    "@pugi/cli-windows-x64": "1.0.0-alpha.159"
   }
 }

package/skills/css-tailwind/SKILL.md

@@ -17,6 +17,11 @@ Refactors CSS to Tailwind, fixes spacing rhythm, ensures dark/light parity.
 - Both themes are shipped. A colour that only reads on the dark ground is a bug on the light one; take colour from variables so the theme decides.
 
 
+## Known failure modes
+
+Read `quirks.md` in this directory BEFORE writing code in this domain. It records 5 failures that reached a customer build, each with the symptom, the cause, and the check that tells them apart.
+
+
 ## Grounding
 
 This skill retrieves from the Anvil RAG workspace `ui_registry`. Ask grounded questions in that domain before inventing answers.

package/skills/css-tailwind/quirks.md

@@ -0,0 +1,56 @@
+<!-- GENERATED by pugi-core packages/opencode/script/generate-persona-skill-pack.ts — do not hand-edit. -->
+
+# Tailwind Polish — known failure modes
+
+Each entry below reached a customer build. The symptom is what you will
+actually observe; the build succeeds in every one of these cases.
+
+## v3-directives-under-v4
+
+**Symptom.** The build succeeds and the page renders with NO styling at all — plain black text on white, browser default fonts.
+
+**Cause.** The stylesheet still opens with the v3 directives `@tailwind base/components/utilities` while package.json pins tailwindcss v4. Those directives do not exist in v4, so PostCSS emits no utility classes and reports no error.
+
+**Check.** Read the tailwindcss version in package.json, then the first lines of src/index.css. v4 must open with `@import "tailwindcss";`.
+
+**Fix.** Replace the three directives with `@import "tailwindcss";`, or put tailwindcss back on ^3 and use `tailwindcss: {}` in postcss.config.js instead of `@tailwindcss/postcss`. The two halves must agree.
+
+## palette-in-root-without-theme
+
+**Symptom.** Layout works — spacing, flex, max-width all apply — but every colour is missing: no backgrounds, no surfaces, text is default black.
+
+**Cause.** The palette is declared as `--color-*` variables inside `:root`. v4 turns a variable into a utility class only when it is declared inside an `@theme` block, and it ignores tailwind.config.js unless the stylesheet asks with `@config`.
+
+**Check.** If `:root` contains `--color-` and the file has neither `@theme` nor `@config`, the token classes generate nothing. Confirm by grepping the BUILT css for one token class, e.g. `bg-background`.
+
+**Fix.** Move the palette into an `@theme` block, or add `@config "./tailwind.config.js";`. Then grep the built css for the classes the components use before reporting done.
+
+## unlayered-global-reset
+
+**Symptom.** Colours and borders are correct but the page has no rhythm — `px-4` computes to 0px, `mx-auto` does not centre, nothing has margins.
+
+**Cause.** A global `* { margin: 0; padding: 0 }` sits outside any `@layer`. v4 puts its utilities in cascade layers, and unlayered css beats layered css regardless of specificity, so one rule overrides every spacing utility at once.
+
+**Check.** Search the stylesheet for a `*` selector setting margin or padding that is not inside `@layer`. Then inspect a padded element in the browser and read the computed padding.
+
+**Fix.** Wrap the reset in `@layer base { ... }`, or delete it — Tailwind's own preflight already does this job.
+
+## v4-entry-under-v3
+
+**Symptom.** The build succeeds and the page renders unstyled, the mirror image of the first quirk.
+
+**Cause.** The stylesheet uses the v4 entry `@import "tailwindcss"` while package.json pins tailwindcss v3, which does not understand it.
+
+**Check.** Compare the pinned major in package.json against the stylesheet entry line. They must agree.
+
+**Fix.** Use the v3 directives for a v3 pin, or move the pin to v4. Do not mix the two dialects.
+
+## dev-script-not-at-root
+
+**Symptom.** The app builds and runs, but the hosted preview shows nothing or a 503 — the runner reports it found no dev command.
+
+**Cause.** In a monorepo the dev script lives in a workspace package (apps/web, packages/web, client, frontend) or is named `dev:web` rather than `dev`, and a root-only lookup misses it.
+
+**Check.** Read the root package.json scripts, then the workspace package's own scripts before concluding there is no dev command.
+
+**Fix.** Declare the runnable script at the root, or make sure the app directory is the one handed to the runner. State the app directory explicitly rather than letting it be guessed.

package/skills/nestjs-api/SKILL.md

@@ -9,6 +9,16 @@ description: "Generates idiomatic NestJS modules, controllers, services, DTOs."
 
 Generates idiomatic NestJS modules, controllers, services, DTOs.
 
+## Rules
+
+- Every dependency you import must be in package.json before you import it. A test file is code: importing `@nestjs/testing` without adding it fails the build for the whole project, not just the test.
+- Run the project's own build once before reporting done. `tsc` is the cheapest reviewer you have and it reads the tsconfig the customer will ship with, not the one you assumed.
+
+
+## Known failure modes
+
+Read `quirks.md` in this directory BEFORE writing code in this domain. It records 2 failures that reached a customer build, each with the symptom, the cause, and the check that tells them apart.
+
 
 ## Grounding
 

package/skills/nestjs-api/quirks.md

@@ -0,0 +1,26 @@
+<!-- GENERATED by pugi-core packages/opencode/script/generate-persona-skill-pack.ts — do not hand-edit. -->
+
+# NestJS API Builder — known failure modes
+
+Each entry below reached a customer build. The symptom is what you will
+actually observe; the build succeeds in every one of these cases.
+
+## strict-property-initialization
+
+**Symptom.** The build fails with `TS2564: Property 'x' has no initializer and is not definitely assigned in the constructor` on every DTO field.
+
+**Cause.** The NestJS starter enables `strictPropertyInitialization`. A DTO declares fields the framework fills at runtime from the request body, which the compiler cannot see.
+
+**Check.** Read `strict` and `strictPropertyInitialization` in tsconfig.json before writing the first DTO.
+
+**Fix.** Declare DTO fields with the definite-assignment marker — `image!: string` — or give them a default. Do not disable the compiler flag to make the error go away: it protects the rest of the code.
+
+## test-imports-uninstalled-package
+
+**Symptom.** The build fails with `TS2307: Cannot find module '@nestjs/testing'` even though the application code is fine.
+
+**Cause.** A spec file was written importing the testing utilities, but the package was never added to devDependencies. `tsc -p tsconfig.json` compiles spec files too, so one unbuildable test fails the whole project.
+
+**Check.** Before writing a `.test.ts`/`.spec.ts`, check that every module it imports appears in package.json. `@nestjs/testing` is NOT part of the default starter.
+
+**Fix.** Add the package to devDependencies and install it, or do not write the test. A test that cannot compile is worse than no test — it takes the build down with it.

package/skills/webapp-testing/SKILL.md

@@ -9,6 +9,16 @@ description: "Authors and runs Playwright end-to-end tests against a running web
 
 Authors and runs Playwright end-to-end tests against a running web application.
 
+## Rules
+
+- The platform refuses to deliver an application whose `package.json` has no `test` script, and refuses one whose tests fail. Treat both as part of the definition of done, not as a final formality.
+- Test what the customer will do — open the page, click the main action, read the result. A suite that only asserts a module imports proves the bundler works, not the product.
+
+
+## Known failure modes
+
+Read `quirks.md` in this directory BEFORE writing code in this domain. It records 2 failures that reached a customer build, each with the symptom, the cause, and the check that tells them apart.
+
 
 ## Grounding
 

package/skills/webapp-testing/quirks.md

@@ -0,0 +1,26 @@
+<!-- GENERATED by pugi-core packages/opencode/script/generate-persona-skill-pack.ts — do not hand-edit. -->
+
+# Webapp Testing — known failure modes
+
+Each entry below reached a customer build. The symptom is what you will
+actually observe; the build succeeds in every one of these cases.
+
+## delivery-blocked-by-missing-test-script
+
+**Symptom.** Everything looks finished, then the push is refused with `verification failed: package.json scripts.test is required` and no application is delivered.
+
+**Cause.** The system-owned acceptance gate runs immediately before the authoritative push and requires a real `test` script. It is deliberately not something the model can supply or skip, so it is discovered at the very end.
+
+**Check.** Read `scripts.test` in package.json at the START of the work, not after the build.
+
+**Fix.** Define a `test` script that actually runs the suite, and make it pass. A placeholder that exits 0 satisfies the letter of the gate and delivers an untested app — write the tests instead.
+
+## unbuildable-test-fails-the-whole-project
+
+**Symptom.** The application code compiles when you check it, but the delivery gate reports `pugi verification: test` and the push is refused.
+
+**Cause.** The project's build compiles spec files too. A test importing a package that was never added to package.json, or a type error inside a test, fails the whole compile — the application is fine and still cannot ship.
+
+**Check.** Run the project's own build once with the tests in place, before reporting done.
+
+**Fix.** Add every package a test imports to devDependencies, or delete the test. A test that cannot compile is worse than no test: it takes the delivery down with it.