generator-folklore 3.0.54 → 3.0.56

package/lib/generators/agents/index.js

@@ -22,7 +22,7 @@ class AgentsGenerator extends _generator.default {
     const hasPackageJson = this.fs.exists(this.destinationPath('package.json'));
     const existingContent = this.fs.exists(destPath) ? this.fs.read(destPath) : '';
     const separator = '\n\n---\n\n';
-    const parts = [this.fs.read(this.templatePath('general.md')), hasComposerJson ? this.fs.read(this.templatePath('laravel.md')) : null, hasPackageJson ? this.fs.read(this.templatePath('frontend.md')) : null, this.fs.read(this.templatePath('after.md'))].filter(it => it !== null).join(separator);
+    const parts = [this.fs.read(this.templatePath('general.md')), this.fs.read(this.templatePath('workflow.md')), hasComposerJson ? this.fs.read(this.templatePath('laravel.md')) : null, hasPackageJson ? this.fs.read(this.templatePath('frontend.md')) : null, hasComposerJson ? this.fs.read(this.templatePath('serve-laravel.md')) : null, !hasComposerJson && hasPackageJson ? this.fs.read(this.templatePath('serve-html.md')) : null, this.fs.read(this.templatePath('after.md'))].filter(it => it !== null).join(separator);
     const newContent = existingContent.length > 0 ? `${existingContent}${separator}${parts}` : parts;
     this.fs.write(destPath, newContent);
   }

package/lib/generators/agents/templates/general.md

@@ -8,8 +8,8 @@ This file defines how coding agents should work in this repository.
 
 ## Language Rules
 
-- Write all code, comments, identifiers, commit messages, and technical docs in English.
-- User-facing chat can be in French, but repository content stays in English.
+- Everything written for people is in French: conversations, GitHub issues and their comments, pull request titles, bodies and review comments.
+- Code is always in English: identifiers, comments, file names, and commit messages.
 
 ## Editing Guidelines
 

package/lib/generators/agents/templates/serve-html.md

@@ -0,0 +1,12 @@
+## Serving the project (HTML, no Laravel backend)
+
+Without a backend, the dev server serves the project directly on `localhost`.
+
+1. Start the dev server over HTTP, without opening a browser: `npm run server -- --server http --no-open`.
+2. Test at `http://localhost:<port>`, the port printed by the dev server (`8080` unless taken).
+
+Notes:
+
+- Options reach `flklr` from `package.json` (`build` key), the environment (`FLKLR_*`) and the command line, the command line winning. Leave `package.json` as is and pass overrides on the command line.
+- HTTP avoids the dev server's self-signed certificate, which browsers reject. Use the default HTTPS only when a feature requires a secure context the browser won't grant to `localhost`.
+- Stop the dev server once testing is done.

package/lib/generators/agents/templates/serve-laravel.md

@@ -0,0 +1,42 @@
+## Serving the project (Laravel)
+
+Always test a Laravel project through its `.test` domain, never `localhost`: some behaviour depends on the domain (multi-site routing, subdomains, absolute URLs, cookies).
+
+1. Valet serves the Laravel app at `https://<project>.test`. Check it with `valet links`.
+2. Start the dev server without opening a browser: `npm run server -- --no-open`. It proxies Valet (`FLKLR_PROXY` in `.env`) and serves the assets with hot reload.
+3. Test at `https://<project>.test:8080`. `flklr serve` picks up the site's Valet certificate on its own (from `~/.config/valet/Certificates`), so the browser trusts it like the site itself.
+
+Notes:
+
+- Options reach `flklr` from `package.json` (`build` key), the environment (`FLKLR_*`) and the command line, the command line winning. Leave `package.json` as is and pass overrides on the command line.
+- On a certificate error, see [Fixing Valet certificates](#fixing-valet-certificates) rather than switching to `localhost` or plain HTTP.
+- Stop the dev server once testing is done.
+
+### Fixing Valet certificates
+
+**Why it breaks.** Valet signs each site's certificate with its own certificate authority (CA), which it adds to the macOS keychain. The browser trusts a site only while that chain holds. When the CA expires (older Valet CAs lasted only two years), the keychain no longer trusts it, or a site certificate is missing or expired, the browser rejects the site: usually `ERR_CERT_DATE_INVALID` or `ERR_CERT_AUTHORITY_INVALID`. The dev server on `:8080` reuses the same certificate, so it breaks at the same time. Renewing the certificates fixes it; switching to `localhost` or plain HTTP only hides it and breaks domain-dependent behaviour.
+
+**Check**
+
+```bash
+npx flklr certificates <project>.test   # one site (a parent domain's certificate counts)
+npx flklr certificates                  # every site secured by Valet
+```
+
+Each line shows ✔ or ✖ with the first problem found, and the command exits with 1 when something fails. The check is read-only, so an agent may run it.
+
+**Fix**
+
+```bash
+npx flklr certificates --fix
+```
+
+- A failing site is secured again with `valet secure`.
+- When the CA is missing, expired or untrusted, the command deletes it and secures every site again: every site certificate depends on the CA, so renewing it alone would break the others.
+- It then runs the check again. Restart `npm run server` and reload the browser, since the dev server reads the certificate at startup.
+
+`--fix` asks for the sudo password and changes the system keychain: an agent explains it and lets the developer run it.
+
+If the check passes but `:8080` is still rejected, `flklr serve` found no certificate for the proxy's host and fell back to its self-signed `localhost` certificate: check that `FLKLR_PROXY` in `.env` uses the `.test` domain.
+
+With Herd instead of Valet, renew certificates from Herd's settings.

package/lib/generators/agents/templates/workflow.md

@@ -0,0 +1,43 @@
+## Development Workflow
+
+Branching follows Gitflow, kept light. `develop` is where development happens: every commit and every merge lands there first. `main` is production: it only receives `develop` when deploying to prod. The backlog is the repository's GitHub Issues; pull requests are where reviewed work lands. Most day-to-day work skips both: the issue/PR flow exists to run work in parallel and to review what deserves it, not to slow down small changes.
+
+On GitHub, `develop` is the default branch (so PRs target it and `Closes #<number>` closes issues on merge), and the `bug`, `enhancement` and `in-progress` labels exist.
+
+### Commit straight to `develop` (default)
+
+- Small changes asked for directly in conversation: fixes, style or copy tweaks, translations, content. The request was reviewed by being asked for.
+- Documentation, comments and config with no runtime effect.
+- Run the checks before committing. Never push unless asked.
+
+### Use an issue and a PR
+
+- A feature or a chunk of work that spans several sessions, or needs a written plan.
+- Work meant to run in parallel with other sessions.
+- Risky or broad changes: migrations, refactors, dependencies, routing, or any diff the maintainer would want to read.
+- Anything started from an existing issue.
+
+What decides the flow is where the request came from and what it touches, not the size of the diff. When unsure, ask.
+
+### Working an issue
+
+1. Read the issue and its comments first; they may change the plan.
+2. Add the `in-progress` label before starting: it stops a second session from picking the same issue. Remove it if the work is abandoned.
+3. For an `enhancement`, write a short plan in the issue body before coding. `bug` issues skip the plan.
+4. One branch per issue, prefixed by its type: `feature/<number>-<slug>` for an `enhancement`, `bug/<number>-<slug>` for a `bug` (other types follow the same pattern, e.g. `docs/`, `refactor/`). Branch from an up-to-date `develop`, in its own worktree under `.claude/worktrees/<number>-<slug>` so parallel sessions don't share a checkout.
+5. Run the checks, push and open the PR against `develop` with `Closes #<number>` in its body, without asking. If the change couldn't be verified in the session, list the test scenario as a checkbox list in the PR body.
+6. The issue closes when the PR merges into `develop`, never just because code was pushed. Remove the worktree (`git worktree remove`) once merged.
+
+Something out of scope noticed along the way becomes a new issue (title, context, files involved) rather than growing the current change. Every issue carries a type label: `bug` or `enhancement`.
+
+### Releasing to production
+
+When deploying, merge `develop` into `main` (only when asked). An urgent fix for prod goes on a `hotfix/<slug>` branch from `main`, merged into `main` and then into `develop` so the two don't diverge.
+
+### Checks
+
+Run the project's lint, format, typecheck and test scripts (see `package.json` and `composer.json`) on what changed. When the codebase has pre-existing errors, a check passes when it reports nothing new in the files touched.
+
+### Rules live in this file
+
+Rules that always apply to this project (workflow, conventions, setup) are written here, not in an agent's private memory, so every session and every teammate shares them.

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "generator-folklore",
-    "version": "3.0.54",
+    "version": "3.0.56",
     "description": "Yeoman generator for projects at Folklore",
     "keywords": [
         "yeoman-generator"
@@ -40,5 +40,5 @@
         "yeoman-generator": "5.9.0",
         "yeoman-remote": "^1.0.1"
     },
-    "gitHead": "9405e6a69d84448512ac33d3bbdb8cac44637140"
+    "gitHead": "588abc69c30c5a8954352431f3aed90375582714"
 }