create-prisma-php-app 5.1.0-alpha.28 → 5.1.0-alpha.30

package/dist/.github/copilot-instructions.md

@@ -51,7 +51,7 @@
 - In Tailwind-enabled Prisma PHP apps, Tailwind utility conflict resolution belongs to the frontend `twMerge(...)` runtime helper.
 - `getMergeClasses(...)` and `PP\PHPX\TwMerge::merge(...)` emit frontend `twMerge(...)` expressions for the browser runtime to resolve.
 - `twMerge(...)` is an app-level browser helper, not a PulsePoint built-in.
-- In TypeScript-enabled apps, Prisma PHP registers that helper from `ts/main.ts`; use `typescript.md` for route usage and `components.md` for PHPX usage.
+- In TypeScript-enabled apps, Prisma PHP registers that helper from `ts/main.ts`; in non-TypeScript Tailwind apps it is registered from `public/js/main.js` (importing `public/js/tailwind-merge.mjs`). Use `typescript.md` for route usage and `components.md` for PHPX usage.
 - Keep Tailwind merge decisions on the frontend runtime instead of trying to finalize conflicting utility classes in PHP.
 
 ## Framework-Managed Package Scripts
@@ -90,6 +90,7 @@
 ## Authentication Route Strategy
 
 - Prisma PHP defaults to public routes.
+- Auth classes are app-owned under `src/Lib/Auth` in the `Lib\Auth` namespace: `use Lib\Auth\Auth;`, `use Lib\Auth\AuthConfig;`, `use Lib\Auth\AuthRole;` — never `PP\Auth\...`.
 - Choose the route privacy strategy at the start of the app, before creating most routes.
 - If the app will have many public pages, keep the public-default strategy.
 - If the app will have only a few public entry points and most routes should require login, use the private-default strategy.
@@ -113,11 +114,11 @@
 
 ## Runtime Wire Contract
 
-- `pp.rpc(functionName, data?, optionsOrAbort?)` is the frontend-to-PHP call API. The former `pp.fetchFunction(...)` no longer exists in the runtime; never generate or document it.
+- `pp.rpc(functionName, data?, optionsOrAbort?)` is the frontend-to-PHP call API.
 - Every function called through `pp.rpc(...)` must be marked `#[Exposed]` on the PHP side.
 - Framework-level RPC failures (unknown function, auth, roles, CSRF, origin, content type, rate limit, server error) arrive as HTTP error statuses with an `{"error": "..."}` JSON body and reject the `pp.rpc(...)` promise; wrap calls in `try/catch` when the UI reacts to failures. Return routine validation feedback as structured data instead of throwing. Throwing `InvalidArgumentException` in an exposed function is the sanctioned validation crossover: its message reaches the caller as a 400.
 - Streamed responses: an exposed function that yields streams SSE `data:` lines; consume them with `onStream`, `onStreamError`, and `onStreamComplete`.
-- CSRF: the runtime reads the `pp_csrf` cookie family (`pp_csrf_<port>` in development, `pp_csrf` otherwise), managed server-side by `PP\Security\Csrf` and signed with `FUNCTION_CALL_SECRET`. Do not document or generate the removed `prisma_php_csrf` cookie.
+- CSRF: the runtime reads the `pp_csrf` cookie family (`pp_csrf_<port>` in development, `pp_csrf` otherwise), managed server-side by `PP\Security\Csrf` and signed with `FUNCTION_CALL_SECRET`.
 - Realtime: use `pp.socket(name, args, handlers)` (named sockets) for long-lived bidirectional flows. Server handlers are registered with `SocketRegistry::register(...)` in `src/Lib/Websocket/sockets.php`; the wire is one endpoint (`/__pulsepoint/ws?name=...`), arguments as the first JSON frame, JSON frames both ways, and `{"error": "..."}` reserved for failures. Do not generate raw `new WebSocket(...)` wiring for app realtime work.
 - Read `node_modules/prisma-php/dist/docs/fetching-data.md`, `bootstrap-runtime.md`, and `websocket.md` for the full contracts.
 
@@ -127,7 +128,7 @@
 - `index.php` and nested `layout.php` must render a single parent HTML element. Treat that root like a component boundary rather than loose sibling markup.
 - If the visible page or layout content should stay inside a semantic element such as `<main>`, `<section>`, or `<article>`, wrap it in a neutral parent such as `<div>` so the route boundary can still own the `<script>`.
 - For pages and nested layouts, author a plain single root element and let Prisma PHP inject the PulsePoint `pp-component` scope automatically.
-- Author plain `<script>` tags inside that boundary root when PulsePoint is needed, usually as a sibling of the visible content container instead of nesting the script inside the semantic content element by default. Put the PulsePoint code at the top level of that script. Do not manually add `type="text/pp"`, `DOMContentLoaded` wrappers, IIFEs, or manual bootstrap code; Prisma PHP normalizes the script contract for the runtime.
+- Author plain `<script>` tags inside that boundary root when PulsePoint is needed, usually as a sibling of the visible content container instead of nesting the script inside the semantic content element by default. Put the PulsePoint code at the top level of that script. Never put a `type` attribute on a component script — the runtime only recognizes untyped scripts. Do not add `DOMContentLoaded` wrappers, IIFEs, or manual bootstrap code.
 - Do not leave the route `<script>` outside the route boundary.
 - Only the root `layout.php` should define `<html>`, `<head>`, and `<body>`. When PulsePoint is present, keep `MainLayout::$children;` and any `<script>` inside one clear wrapper.
 
@@ -136,7 +137,7 @@
 - Distinguish PHPX class components from `ImportComponent` partials.
 - `ImportComponent` partials must output exactly one root element because Prisma PHP uses that root as the imported component boundary and serializes props there.
 - Do not manually add `pp-component` inside `ImportComponent` partial source; Prisma PHP injects it there.
-- When imported partials need PulsePoint logic, keep the `<script>` inside that same root element and author it as a plain `<script>` tag without `type="text/pp"`, DOM-ready wrappers, or manual bootstrap code.
+- When imported partials need PulsePoint logic, keep the `<script>` inside that same root element and author it as a plain `<script>` tag with no `type` attribute (the runtime ignores typed scripts), without DOM-ready wrappers or manual bootstrap code.
 
 ## Validation Rules
 

package/dist/AGENTS.md

@@ -173,7 +173,7 @@ Use the docs router to learn how Prisma PHP implements a task. Use `./prisma-php
 - **API-style routes, JSON responses, handlers, webhooks, form-processing endpoints, `route.php`, or request validation in handlers**  
   Read `route-handlers.md`
 
-- **Swagger or OpenAPI generation, `swaggerDocs`, `pphp-swagger.json`, `create-swagger-docs`, or `settings/prisma-schema-config.json`**  
+- **Swagger or OpenAPI generation, `swaggerDocs`, generated per-model swagger docs, `create-swagger-docs`, or `settings/prisma-schema-config.json`**  
   Read `swagger-docs.md`
 
 - **Writing or running app tests, PHPUnit, the root `tests/` directory, `npm run test`, or verifying a change with the test suite**  
@@ -329,7 +329,7 @@ Default interaction stack:
 5. validate and normalize input on the PHP side with `PP\Validator`
 6. use `pp.socket(...)` (named sockets) only when the flow is genuinely long-lived and bidirectional — chat, presence, live feeds
 
-`pp.rpc(...)` is the current runtime API. The former `pp.fetchFunction(...)` does not exist any more — never generate or document it. Framework-level RPC failures (unknown function, auth, roles, CSRF, origin, rate limit, server error) arrive as HTTP error statuses with an `{"error": "..."}` body and **reject** the `pp.rpc(...)` promise, so wrap calls in `try/catch` when the UI reacts to failures. Routine, expected validation feedback should still be returned as structured data (`success`, `errors`, normalized values), not thrown.
+`pp.rpc(...)` is the runtime RPC API. Framework-level RPC failures (unknown function, auth, roles, CSRF, origin, rate limit, server error) arrive as HTTP error statuses with an `{"error": "..."}` body and **reject** the `pp.rpc(...)` promise, so wrap calls in `try/catch` when the UI reacts to failures. Routine, expected validation feedback should still be returned as structured data (`success`, `errors`, normalized values), not thrown.
 
 Treat this as the default for:
 
@@ -379,7 +379,7 @@ Also follow these route-file rules:
 - `index.php` and nested `layout.php` must render a single parent HTML element
 - use that single parent element as the route boundary; if the visible content should stay inside a semantic element such as `<main>`, `<section>`, or `<article>`, wrap it in a neutral parent such as `<div>`
 - for normal pages and nested layouts, do **not** manually author `pp-component` on that root; Prisma PHP adds it automatically
-- author a plain `<script>` tag inside that root when PulsePoint logic is needed and do **not** add `type="text/pp"` manually
+- author a plain `<script>` tag inside that root when PulsePoint logic is needed and do **not** put any `type` attribute on it — the runtime only recognizes untyped component scripts
 - keep the `<script>` as the last child of the route boundary, usually as a sibling of the visible content container instead of nesting it inside the semantic content element by default
 - do **not** leave the `<script>` outside the route boundary
 - write PulsePoint state, derived values, and functions directly at the top level of that script; do **not** wrap them in `DOMContentLoaded`, an IIFE, manual `pp.mount()` calls, or custom scoping helpers
@@ -439,7 +439,7 @@ Do not:
 
 - put a sibling `<script>` next to a route root or imported partial root
 - manually add `pp-component` inside imported partial source
-- manually add `type="text/pp"` to route or imported-partial scripts
+- add any `type` attribute to route or imported-partial component scripts
 - wrap imported-partial PulsePoint code in `DOMContentLoaded`, an IIFE, manual `pp.mount()` calls, or custom auto-execute helpers
 
 ## Metadata rules
@@ -531,6 +531,7 @@ Use this auth decision flow:
 
 Important auth rules:
 
+- the auth classes are app-owned files under `src/Lib/Auth` in the `Lib\Auth` namespace — write `use Lib\Auth\Auth;` and `use Lib\Auth\AuthConfig;`, never `PP\Auth\...`
 - route privacy strategy is configured from `AuthConfig.php`
 - Prisma PHP supports both public-default and private-default route protection strategies
 - Prisma PHP defaults to public routes, so keep the public-default strategy when the app will expose many public pages

package/dist/src/Lib/MCP/mcp-server.php

@@ -68,9 +68,8 @@ try {
         $port,
         $prefix,
         null,            // sslContext
-        true,            // logger
-        $enableJson      // enableJsonResponse
-        // , false        // (optional) stateless
+        $enableJson,     // enableJsonResponse
+        false            // stateless
     );
     echo $color("✓ Listening on {$base}", '32') . PHP_EOL;
     $server->listen($transport);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-prisma-php-app",
-  "version": "5.1.0-alpha.28",
+  "version": "5.1.0-alpha.30",
   "description": "Prisma-PHP: A Revolutionary Library Bridging PHP with Prisma ORM",
   "main": "dist/index.js",
   "type": "module",