Bump version to 0.28.0

CHANGELOG.md

@@ -4,6 +4,47 @@ All notable changes to this project will be documented in this file.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
+## [0.28.0] - 2026-09-30
+### Added
+- `php artisan boboko:translations:pull` — the reverse of the translation
+  seeders: copies `storefront` / `checkout` / `validation` lines that exist in
+  the database (e.g. added through the Filament Language Lines UI while
+  building a storefront) but not in the matching seeder into that seeder's
+  `lines()`, appended under a marker comment. Keys a seeder already has are
+  never touched. Writes only against a local `../boboko-core` checkout (local
+  mode); `--dry-run` lists the lines from anywhere.
+- Storefront translations for error pages: `storefront.errors.404_title`,
+  `storefront.errors.404_text`, `storefront.errors.back_home`. Re-run
+  `StorefrontTranslationsSeeder` in consuming apps (or restart the stack) to
+  add them.
+
+### Changed
+- `CONTRIBUTE.md` rewritten to match the actual setup: the local/repo modes
+  and the `bin/core-mode` switch, `@boboko/core` as a real npm package (the
+  old "no separate npm package" section was stale), releasing a version,
+  deploying a consumer app with `bin/deploy`, and pulling UI-added
+  translations into the seeders.
+
+## [0.27.5] - 2026-09-30
+### Security
+- OTP codes (both customer login via `UserOtpService` and staff login via
+  `OtpService`) were stored in plaintext in `users.otp_code`/`lunar_staff.otp_code`
+  and compared against the plaintext guess. The staff path was additionally
+  weaker — a loose `!=` comparison with no timing-attack protection and no
+  attempt-limiting at all. Both columns are replaced with `otp_code_hash`
+  (bcrypt, via a `'hashed'` cast — same convention `password` already uses),
+  compared with `Hash::check()`. The cache-backed pending-signup OTP path
+  (an email with no `User` row yet) is hashed the same way. No backfill —
+  any code mid-flight when this deploys is invalidated (codes expire in 10
+  minutes regardless, so the practical impact is limited to a re-request).
+- `App\Models\User`'s (3dealer) and `Modules\Core\Auth\Models\Staff`'s
+  `$hidden` arrays didn't list `otp_code`/`otp_expires_at`/`otp_attempts`/
+  `pending_email_code_hash`/etc. at all — any serialization of either model
+  (an API response, `Auth::user()` returned somewhere) would have leaked
+  those fields, including the (now-hashed, previously plaintext) OTP code
+  itself. `Staff` additionally never overrode Lunar's own base `$hidden`, so
+  it also lacked `password`/`remember_token` protection until now.
+
 ## [0.27.4] - 2026-09-29
 ### Added
 - Generic `.bbk-notice` / `.bbk-notice--info` message box and a

CONTRIBUTE.md

@@ -1,85 +1,148 @@
 # Contributing to boboko-core
 
-This is a Composer library, not a runnable app — you can't `php artisan serve` it directly. To develop and verify changes, you need a consumer app wired to a local checkout via a Composer path repository, plus a real database, since a large part of this package (Lunar models, migrations, Filament panel resources) can only be meaningfully verified against a live Lunar install.
+This is a Composer library (and an npm package of the same name — see [JS/CSS](#jscss-a-real-npm-package)), not a runnable app — you can't `php artisan serve` it directly. To develop and verify changes, you need a consumer app wired to a local checkout, plus a real database, since a large part of this package (Lunar models, migrations, Filament panel resources) can only be meaningfully verified against a live Lunar install.
 
 ## Local dev setup
 
-This works against any consumer app that follows the same convention — `boboko-test`, `boboko-starter`, `boboko-3dealer`, etc. — checked out next to this repo:
+Consumer apps (`3dealer`, `boboko-test`, …) are checked out next to this repo:
 
 ```
 RadicalElements/
 ├── boboko-core/    (this repo)
-└── boboko-test/    (or boboko-starter, boboko-3dealer, ... — consumer app, Docker-based)
+└── 3dealer/        (or boboko-test, ... — consumer app, Docker-based)
 ```
 
-Each of these consumer apps ships a `bin/dc-core.sh` helper that wraps the Docker Compose overlay needed to bind-mount a local `boboko-core` checkout into the app container:
+### Two modes: local and repo
+
+A consumer app can consume core in one of two modes, and carries the wiring for both. The inactive one is parked under an underscore-prefixed key:
+
+| | **local** — your `../boboko-core` checkout | **repo** — tagged releases from the forge |
+|---|---|---|
+| `composer.json` | `repositories`: path repo `../boboko-core` (`"symlink": true`) | `repositories`: VCS repo `https://code.radical-elements.com/boboko/core.git` |
+| `package.json` | `@boboko/core`: `file:../boboko-core` | `@boboko/core`: `git+https://code.radical-elements.com/boboko/core.git#semver:0.x` |
+| Docker Compose | `bin/dc-core.sh` (dev + `docker-compose.core-dev.yml` overlay) | `bin/dc` (dev only) |
+
+- **The committed state is always repo mode.** Local mode rewrites both lockfiles to point at `../boboko-core`, which doesn't exist on the server — never commit it.
+- Both sides use an open `0.x` range: `"boboko/core": "0.*"` in Composer, `#semver:0.x` in npm. Don't use a caret: below 1.0.0, `^0.27.0` means `>=0.27.0 <0.28.0` in both tools, so it would silently refuse the next minor.
+- `docker-compose.core-dev.yml` bind-mounts `../boboko-core` into the containers — at `/var/www/boboko-core` for `app`/`queue`/`scheduler` (where the path repo resolves from `/var/www/html`) and at `/boboko-core` for `vite` (where `file:../boboko-core` resolves from `/app`). Inside the app container, `vendor/boboko/core` is a symlink into that mount.
+
+### Switching modes: `bin/core-mode`
+
+Don't swap the keys by hand — each consumer app ships a `bin/core-mode` script:
 
 ```bash
-./bin/dc-core.sh exec app <command>
+bin/core-mode          # print the current mode
+bin/core-mode local    # work against ../boboko-core
+bin/core-mode repo     # back to tagged releases
 ```
 
-This is shorthand for `docker compose -f docker-compose.dev.yml -f docker-compose.core-dev.yml exec app <command>`. Use `./bin/dc-core.sh` for everything below instead of typing the full compose invocation.
+It swaps the `composer.json` / `package.json` wiring, runs `down` with the old mode's Compose wrapper and `up` with the new one, then waits until the entrypoints have re-resolved core. Running it for the mode you're already in skips the edits and just restarts the stack — in repo mode, that's how you pick up a newly pushed tag.
 
-1. **Path repository.** In the consumer app's `composer.json`, the `repositories` array needs a path entry pointing at `../boboko-core`. If it only exists in a disabled block (e.g. `_repositories`), move it into the live array.
-2. **Relaxed version constraint.** The consumer app's `composer.json` should require `"boboko/core": "0.*"` (not a tight `^0.0.1` caret) — otherwise Composer rejects newer `0.0.x` versions resolved from the path repo.
-3. **Bind mount.** The consumer app's `docker-compose.core-dev.yml` overlays `../boboko-core` into the container at `/var/www/boboko-core`, matching where the path repo resolves it relative to `/var/www/html`.
-4. **Re-resolve after every change.** Composer's path repo does not hot-reload — after editing anything in `boboko-core` (including adding new files, which need autoload discovery), the container needs to re-run `composer update boboko/core`. In `boboko-test`, the entrypoint does this automatically on every dev boot (see `docker/entrypoint.sh`), so `./bin/dc-core.sh up` alone picks up local core changes. If a consumer app's entrypoint doesn't do this yet, run it manually:
+(`3dealer` has `bin/core-mode` and `bin/deploy`; they're app-agnostic, so other consumer apps can copy them as-is.)
+
+### Day to day in local mode
+
+Use `bin/dc-core.sh` for every Compose command (`bin/dc-core.sh exec app …`, `bin/dc-core.sh logs -f`, …) — plain `docker compose` or `bin/dc` leaves the core mount out.
+
+The dev entrypoints re-resolve core on **every boot**: `docker/entrypoint.sh` runs `composer update "boboko/*"` and `docker/entrypoint-vite.sh` runs `npm update @boboko/core`. So:
+
+- **Whatever branch is checked out in `../boboko-core` is what the app runs.** Switching core branches switches the app's code — check which branch you're on before debugging "missing" features.
+- PHP edits to existing files show up immediately (it's a symlink). **New classes, new migrations, or `composer.json` changes** need a re-resolve: restart the stack, or run
 
   ```bash
-   ./bin/dc-core.sh exec app composer update boboko/core --with-all-dependencies
+  bin/dc-core.sh exec app composer update boboko/core --with-all-dependencies
   ```
 
-   Skipping this step is the most common cause of "my change isn't showing up."
+  Skipping this is the most common cause of "my change isn't showing up."
+- In `3dealer`, the app container's `vendor/` is a named Docker volume, so the host's `vendor/` directory is stale — inspect packages inside the container, not on the host.
 
-## JS/CSS: no separate npm package
+## JS/CSS: a real npm package
 
-This package's JS (Stimulus controllers) and CSS ship as plain source files under `resources/js/` and `resources/css/`, read directly by a consumer app's own Vite build — there is no separate `@boboko/core` npm package, and no `npm install`/`file:` dependency step of any kind.
+Core's Stimulus controllers and CSS ship as the `@boboko/core` npm package, installed into the consumer's `node_modules` — as a symlink to `../boboko-core` in local mode, as a real copy of the tagged release in repo mode. It's a real package (rather than files read out of `vendor/`) so npm installs core's own dependencies (`leaflet`, `@hotwired/stimulus`) transitively, the same way Composer does for PHP.
 
-The reason: Composer already gives every environment one single, unconditional path — `vendor/boboko/core` — whether that resolves to a real symlink into `../boboko-core` (local path repo) or a real installed copy (tagged VCS release). A consumer's `vite.config.js` and JS entry point just read straight from that path, so there is nothing to toggle on the JS side — whatever Composer resolved is exactly what Vite sees, automatically, in both dev and prod.
+Public entry points (`package.json` `exports`):
 
-**Stable entry point.** A consumer imports from [resources/js/index.js](resources/js/index.js) only — never from a path reaching into a specific module's internals (e.g. `resources/js/checkout/index.js` directly). That barrel file re-exports whatever a consumer needs (currently just `registerCheckout`), so this package's internal file layout can change without breaking every consumer's own entry point:
+| Import | File |
+|---|---|
+| `@boboko/core` | `resources/js/index.js` — the stable barrel (`registerCheckout`, `registerWishlist`, …) |
+| `@boboko/core/vite-plugin` | `vite-plugin.js` — `boboko()` |
+| `@boboko/core/css/*` | `resources/css/*` |
+| `@boboko/core/checkout`, `@boboko/core/checkout/*` | `resources/js/checkout/…` |
+
+A consumer imports from the `@boboko/core` barrel only — not from a module's internal files — so the internal layout here can change without breaking every consumer:
 
 ```js
 // consumer app's resources/js/app.js
-import { registerCheckout } from "../../vendor/boboko/core/resources/js/index.js";
+import { registerCheckout, registerWishlist } from "@boboko/core";
 registerCheckout(application);
+registerWishlist(application);
+```
+
+```js
+// consumer app's vite.config.js
+import { boboko } from "@boboko/core/vite-plugin";
+
+export default defineConfig({
+    plugins: [
+        laravel({
+            input: [
+                // Core's structural checkout styles load first, so the app's own theming wins.
+                "node_modules/@boboko/core/resources/css/checkout.css",
+                "resources/css/app.css",
+                "resources/js/app.js",
+            ],
+        }),
+        boboko(),
+    ],
+});
 ```
 
 ```php
 {{-- consumer app's layout --}}
-@vite(['vendor/boboko/core/resources/css/checkout.css', 'resources/css/app.css', 'resources/js/app.js'])
+@vite(['node_modules/@boboko/core/resources/css/checkout.css', 'resources/css/app.css', 'resources/js/app.js'])
 ```
 
-**What a consumer's `vite.config.js` needs**, because `vendor/boboko/core` is a symlink in local path-repo dev (not a real directory):
+`boboko()` owns the Vite settings the local-mode symlink needs, so consumers don't hand-copy them: it excludes `@boboko/core` from dependency pre-bundling (otherwise Vite serves a stale cached copy after you edit core), pre-bundles `leaflet`/`@hotwired/stimulus` explicitly, and turns on `resolve.preserveSymlinks` and `server.watch.followSymlinks` so bare imports resolve from the consumer's `node_modules` and core edits trigger HMR. All of it is a harmless no-op against a real installed copy in repo mode.
 
-```js
-export default defineConfig({
-    server: {
-        watch: {
-            // vendor/boboko/core is a symlink into ../boboko-core in local
-            // path-repo dev. Vite/chokidar don't follow symlinks for watched
-            // files by default, so edits to core's source wouldn't otherwise
-            // trigger HMR. No-op against a real installed copy (tagged VCS
-            // release) in production — there's no symlink to follow, and
-            // production only ever runs a one-shot `npm run build`, which
-            // doesn't watch anything regardless.
-            followSymlinks: true,
-        },
-    },
-});
+## Translations added in the UI
+
+Default translation lines ship in core's seeders (`StorefrontTranslationsSeeder`, `CheckoutTranslationsSeeder`, `ValidationTranslationsSeeder`), which every app runs on boot and which only ever add missing keys. Lines added while building a storefront usually start in the Filament Language Lines UI instead. To move them into core:
+
+```bash
+bin/dc-core.sh exec app php artisan boboko:translations:pull            # local mode: writes into ../boboko-core
+bin/dc exec app php artisan boboko:translations:pull --dry-run          # any mode: just list them
 ```
 
-Bare imports inside this package's own JS (`leaflet`, `@hotwired/stimulus`) resolve against the *consumer's* `node_modules` — Node's normal upward `node_modules` resolution walks from `vendor/boboko/core/resources/js/...` up through `vendor/boboko/`, `vendor/`, to the consumer app's root, where `node_modules` lives. This works with zero extra config as long as `vendor/boboko/core` sits inside the consumer's own directory tree (true for both the symlink and the real-copy case) — a consuming app's `vite`-equivalent Docker service just needs the same bind mount PHP containers already get, landing at the same path:
+It adds every `storefront` / `checkout` / `validation` key that's in the database but not in the matching seeder, appended at the end of `lines()` under a marker comment — move them into the right section before committing. Keys the seeder already has are never touched, even if their text was edited in the UI. `bin/deploy` runs it for you.
 
-```yaml
-# consumer app's docker-compose.core-dev.yml
-services:
-  vite:
-    volumes:
-      - ../boboko-core:/app/vendor/boboko/core
+## Releasing a version
+
+1. Bump `"version"` in **both** `composer.json` and `package.json` — they must match.
+2. Add a `CHANGELOG.md` entry under the new version. While pre-1.0, a new capability for consuming apps is a **minor** bump (`0.27.x` → `0.28.0`); a fix, redesign or internal swap with no new capability is a **patch** bump.
+3. Commit, tag `vX.Y.Z`, and push the commit **and** the tag:
+
+   ```bash
+   git tag v0.27.5
+   git push origin master v0.27.5
    ```
 
-(Match whatever the consumer's Vite container's working directory actually is — `/app` above, `/var/www/html` for the PHP containers in `boboko-test`'s convention.)
+A tag alone changes nothing in production — each consumer app has to pick it up and deploy (below).
+
+## Deploying a consumer app
+
+Production only ever runs what the app's **committed lockfiles** pin. Each consumer app ships `bin/deploy`, which:
+
+1. Refuses to run on the wrong branch, with uncommitted changes (other than the core wiring files), or behind `origin`.
+2. Runs `php artisan boboko:translations:pull` (see [Translations added in the UI](#translations-added-in-the-ui)). In local mode, if it pulls any lines into `../boboko-core`, it stops — commit, tag and push core, then rerun. In repo mode it only checks, and stops if the database has lines core doesn't.
+3. Runs `bin/core-mode repo` — switching from local mode if needed, restarting either way — so both lockfiles resolve the newest `0.x` tag. It warns if `../boboko-core` has a newer tag than what resolved (usually an unpushed tag).
+4. Commits the lockfile bump (`Chore: Bumping boboko/core to X.Y.Z`) if there is one, shows what will be pushed, and asks for confirmation.
+5. Pushes, then runs `vendor/bin/envoy run deploy` against the host in `.env.envoy`.
+
+Envoy (`Envoy.blade.php`) then, on the server: `git reset --hard` + `git pull`, `docker compose build` (the `production` image target runs `composer install --no-dev` and `npm ci` from the committed lockfiles — this is where the core tag actually lands), `up -d`, caches config/routes/events, restarts `queue` and `scheduler`, and regenerates Stoic thumbnails. The production entrypoint skips Composer entirely and runs migrations (including core's), seeders, the Meilisearch sync, and `artisan optimize`.
+
+After deploying you're left in repo mode — `bin/core-mode local` to go back.
+
+When a change spans core and the app (e.g. a core migration plus an app model cast that depends on it), ship them together: tag core first, then commit the app change and deploy — `bin/deploy` bumps the lock to the new tag in the same deploy.
 
 ## Verifying changes against a real database
 

composer.json

@@ -2,7 +2,7 @@
   "name": "boboko/core",
   "description": "Core module — authentication and shared panel behaviour",
   "type": "library",
-  "version": "0.27.4",
+  "version": "0.28.0",
   "autoload": {
     "psr-4": {
       "Modules\\Core\\": "src/"

database/migrations/2026_09_30_000001_hash_otp_code_on_users_table.php

@@ -0,0 +1,43 @@
+<?php
+
+use Illuminate\Database\Migrations\Migration;
+use Illuminate\Database\Schema\Blueprint;
+use Illuminate\Support\Facades\Schema;
+
+/**
+ * otp_code was stored in plaintext (a raw 6-digit string) and compared
+ * with hash_equals() against the plaintext guess in
+ * Modules\Core\Auth\Services\UserOtpService — hash_equals() only
+ * prevents a timing attack, it does nothing to protect the code itself
+ * from anyone with read access to the row. Replaced with a bcrypt hash,
+ * same pattern Modules\Core\Customer\Services\CustomerEmailChangeService
+ * already uses for its own pending_email_code_hash column.
+ *
+ * No backfill: any code mid-flight when this deploys is invalidated —
+ * codes expire in 10 minutes anyway, so the real-world impact is a
+ * shopper re-requesting one, not lost work.
+ */
+return new class extends Migration
+{
+    public function up(): void
+    {
+        Schema::table('users', function (Blueprint $table) {
+            $table->string('otp_code_hash')->nullable()->after('password');
+        });
+
+        Schema::table('users', function (Blueprint $table) {
+            $table->dropColumn('otp_code');
+        });
+    }
+
+    public function down(): void
+    {
+        Schema::table('users', function (Blueprint $table) {
+            $table->string('otp_code', 6)->nullable()->after('password');
+        });
+
+        Schema::table('users', function (Blueprint $table) {
+            $table->dropColumn('otp_code_hash');
+        });
+    }
+};

database/migrations/2026_09_30_000002_hash_otp_code_on_lunar_staff_table.php

@@ -0,0 +1,37 @@
+<?php
+
+use Illuminate\Database\Migrations\Migration;
+use Illuminate\Database\Schema\Blueprint;
+use Illuminate\Support\Facades\Schema;
+
+/**
+ * Same fix as 2026_09_30_000001_hash_otp_code_on_users_table.php, for
+ * staff logins — see that migration's own docblock. This path was
+ * additionally weaker: Modules\Core\Auth\Services\OtpService compared
+ * with a loose != rather than hash_equals(), so it had no timing-attack
+ * protection at all on top of the plaintext storage.
+ */
+return new class extends Migration
+{
+    public function up(): void
+    {
+        Schema::table('lunar_staff', function (Blueprint $table) {
+            $table->string('otp_code_hash')->nullable()->after('password');
+        });
+
+        Schema::table('lunar_staff', function (Blueprint $table) {
+            $table->dropColumn('otp_code');
+        });
+    }
+
+    public function down(): void
+    {
+        Schema::table('lunar_staff', function (Blueprint $table) {
+            $table->string('otp_code', 6)->nullable()->after('password');
+        });
+
+        Schema::table('lunar_staff', function (Blueprint $table) {
+            $table->dropColumn('otp_code_hash');
+        });
+    }
+};

docs/lunar.md

@@ -393,7 +393,7 @@ Because Filament instantiates `Lunar\Admin\Models\Staff` directly (not a subclas
 ```php
 use Lunar\Admin\Models\Staff as LunarStaff;
 
-LunarStaff::addActivitylogExcept(['otp_code', 'otp_expires_at', 'password']);
+LunarStaff::addActivitylogExcept(['otp_code_hash', 'otp_expires_at', 'password']);
 ```
 
 ---

docs/otp-auth.md

@@ -30,11 +30,12 @@ Codes expire after **10 minutes**. After a successful validation the code is cle
 
 ### Database
 
-Two columns on the `lunar_staff` table (added by `2026_05_06_000001_add_otp_to_lunar_staff_table`):
+Two columns on the `lunar_staff` table (added by `2026_05_06_000001_add_otp_to_lunar_staff_table`,
+`otp_code` replaced with a hashed column by `2026_09_30_000002_hash_otp_code_on_lunar_staff_table`):
 
 | Column | Type | Purpose |
 |---|---|---|
-| `otp_code` | string, nullable | The generated code |
+| `otp_code_hash` | string, nullable | Bcrypt hash of the generated code (`'hashed'` cast on `Staff`) |
 | `otp_expires_at` | timestamp, nullable | Expiry time |
 
 ### Login Page

package.json

@@ -1,6 +1,6 @@
 {
     "name": "@boboko/core",
-    "version": "0.27.4",
+    "version": "0.28.0",
     "private": true,
     "type": "module",
     "description": "Portable Stimulus controllers and styles for boboko-core's cart + checkout module. Installed as a real npm dependency (file:../boboko-core in dev, a tagged git install in prod) so a consuming app's `npm install` resolves this package's own dependencies (leaflet, @hotwired/stimulus) transitively, the same way `composer update boboko/*` does for PHP. See CONTRIBUTE.md's \"JS/CSS: a real npm package\" section.",

resources/js/index.js

@@ -1,5 +1,5 @@
 // Single stable JS entry point for this package. A consuming app imports
-// from here (vendor/boboko/core/resources/js/index.js), never from a path
+// from here (`import { … } from "@boboko/core"`), never from a path
 // reaching into a specific module's internals — so this file's exports can
 // grow or its modules' internal layout can change without breaking every
 // consumer's own entry point.

src/Auth/Models/Staff.php

@@ -11,7 +11,7 @@ class Staff extends ModelsStaff
         'last_name',
         'admin',
         'email',
-        'otp_code',
+        'otp_code_hash',
         'otp_expires_at',
     ];
 
@@ -19,6 +19,18 @@ class Staff extends ModelsStaff
         'admin' => 'bool',
         'email_verified_at' => 'datetime',
         'password' => 'hashed',
+        'otp_code_hash' => 'hashed',
         'otp_expires_at' => 'datetime',
     ];
+
+    // Overrides (doesn't merge with) Lunar\Admin\Models\Staff's own
+    // $hidden — repeats its password/remember_token here so this class
+    // doesn't silently drop that protection while adding otp_code_hash/
+    // otp_expires_at, which the base model has no reason to know about.
+    protected $hidden = [
+        'password',
+        'remember_token',
+        'otp_code_hash',
+        'otp_expires_at',
+    ];
 }

src/Auth/Services/OtpService.php

@@ -2,6 +2,7 @@
 
 namespace Modules\Core\Auth\Services;
 
+use Illuminate\Support\Facades\Hash;
 use Illuminate\Support\Facades\Mail;
 use Modules\Core\Auth\Mail\OtpMail;
 use Modules\Core\Auth\Models\Staff;
@@ -27,7 +28,10 @@ class OtpService
 
         $code = str_pad((string) random_int(0, 999999), self::CODE_LENGTH, '0', STR_PAD_LEFT);
 
-        $staff->otp_code = $code;
+        // otp_code_hash's 'hashed' cast (see Staff's own $casts) hashes
+        // this automatically on assignment, same as password — never
+        // stored or compared in plaintext.
+        $staff->otp_code_hash = $code;
         $staff->otp_expires_at = now()->addMinutes(self::EXPIRY_MINUTES);
         $staff->save();
 
@@ -44,11 +48,15 @@ class OtpService
             return null;
         }
 
-        if (! $staff->otp_expires_at || $staff->otp_code != $code || now()->isAfter($staff->otp_expires_at)) {
+        if (! $staff->otp_code_hash || ! $staff->otp_expires_at || now()->isAfter($staff->otp_expires_at)) {
             return null;
         }
 
-        $staff->otp_code = null;
+        if (! Hash::check($code, $staff->otp_code_hash)) {
+            return null;
+        }
+
+        $staff->otp_code_hash = null;
         $staff->otp_expires_at = null;
         $staff->save();
 

src/Auth/Services/UserOtpService.php

@@ -8,6 +8,7 @@ use Illuminate\Support\Facades\Auth;
 use Illuminate\Support\Facades\Cache;
 use Illuminate\Support\Facades\DB;
 use Illuminate\Support\Facades\Event;
+use Illuminate\Support\Facades\Hash;
 use Illuminate\Support\Facades\Mail;
 use Illuminate\Support\Facades\RateLimiter;
 use Modules\Core\Auth\Events\UserAuthenticated;
@@ -40,8 +41,11 @@ use Modules\Core\Auth\Mail\UserOtpMail;
  * at all — firstOrCreate() and UserCreated only fire from validate(), and
  * only once the code has actually been proven correct. An email that
  * already has a User row is unaffected: its OTP state still lives on that
- * row's own otp_code/otp_expires_at/otp_attempts columns exactly as
- * before, so a returning shopper's login is unchanged.
+ * row's own otp_code_hash/otp_expires_at/otp_attempts columns exactly as
+ * before, so a returning shopper's login is unchanged. otp_code_hash
+ * holds a bcrypt hash of the code (the 'otp_code_hash' => 'hashed' cast
+ * on App\Models\User hashes it automatically on assignment, same as
+ * password), not the code itself — compared via Hash::check().
  *
  * Two independent throttles, both configured under core.auth.otp — see
  * config/core.php's own comment for why they're separate: max_attempts
@@ -87,7 +91,7 @@ class UserOtpService
         $code = str_pad((string) random_int(0, 999999), self::CODE_LENGTH, '0', STR_PAD_LEFT);
 
         if ($user) {
-            $user->otp_code = $code;
+            $user->otp_code_hash = $code;
             $user->otp_expires_at = now()->addMinutes(self::EXPIRY_MINUTES);
             $user->otp_attempts = 0;
             $user->save();
@@ -96,8 +100,12 @@ class UserOtpService
             // class's own docblock for why: creating one on every
             // generateAndSend() call let anyone mint real User/Customer
             // rows for an email nobody proved they owned.
+            //
+            // Hashed even in the cache (not just on the DB-backed path)
+            // — a code sitting in Cache::get()-able storage is the same
+            // exposure as a plaintext DB column if anything can read it.
             Cache::put($this->pendingKey($email), [
-                'code' => $code,
+                'code_hash' => Hash::make($code),
                 'expires_at' => now()->addMinutes(self::EXPIRY_MINUTES)->timestamp,
                 'attempts' => 0,
             ], now()->addMinutes(self::EXPIRY_MINUTES));
@@ -154,15 +162,15 @@ class UserOtpService
         return DB::transaction(function () use ($model, $email, $code) {
             $user = $model::where('email', $email)->lockForUpdate()->first();
 
-            if (! $user || ! $user->otp_expires_at || now()->isAfter($user->otp_expires_at)) {
+            if (! $user || ! $user->otp_code_hash || ! $user->otp_expires_at || now()->isAfter($user->otp_expires_at)) {
                 return null;
             }
 
-            if (! hash_equals((string) $user->otp_code, $code)) {
+            if (! Hash::check($code, $user->otp_code_hash)) {
                 $user->otp_attempts++;
 
                 if ($user->otp_attempts >= (int) config('core.auth.otp.max_attempts', 5)) {
-                    $user->otp_code = null;
+                    $user->otp_code_hash = null;
                     $user->otp_expires_at = null;
                     $user->otp_attempts = 0;
                 }
@@ -172,7 +180,7 @@ class UserOtpService
                 return null;
             }
 
-            $user->otp_code = null;
+            $user->otp_code_hash = null;
             $user->otp_expires_at = null;
             $user->otp_attempts = 0;
             $user->save();
@@ -200,7 +208,7 @@ class UserOtpService
                 return null;
             }
 
-            if (! hash_equals((string) $pending['code'], $code)) {
+            if (! Hash::check($code, $pending['code_hash'])) {
                 $pending['attempts']++;
 
                 if ($pending['attempts'] >= (int) config('core.auth.otp.max_attempts', 5)) {

src/Command/PullTranslationsCommand.php

@@ -0,0 +1,159 @@
+<?php
+
+namespace Modules\Core\Command;
+
+use Illuminate\Console\Command;
+use Illuminate\Database\Seeder;
+use Modules\Core\Checkout\Database\Seeders\CheckoutTranslationsSeeder;
+use Modules\Core\Localization\Database\Seeders\StorefrontTranslationsSeeder;
+use Modules\Core\Localization\Database\Seeders\ValidationTranslationsSeeder;
+use Modules\Core\Localization\Models\LanguageLine;
+use ReflectionClass;
+use ReflectionMethod;
+
+/**
+ * The reverse of the translation seeders: copies lines added in the Filament
+ * Language Lines UI (e.g. while building the storefront) into the matching
+ * seeder's lines(), so they ship with core and every app gets them.
+ *
+ * Only adds keys the seeder doesn't have yet — a key that already exists in
+ * the seeder is left alone even if its text was edited in the database.
+ * New lines are appended at the end of lines() under a marker comment, to be
+ * moved into the right section by hand.
+ *
+ * Writes into the seeder files the app actually loaded, so it only makes
+ * sense in local mode, where vendor/boboko/core is a symlink to the
+ * ../boboko-core checkout. Against an installed copy it refuses to write;
+ * --dry-run works anywhere.
+ */
+class PullTranslationsCommand extends Command
+{
+    protected $signature = 'boboko:translations:pull {--dry-run : Show what would be added without writing}';
+
+    protected $description = 'Add translation lines that exist in the database but not in the core translation seeders';
+
+    /** @var array<string, class-string<Seeder>> */
+    private const SEEDERS = [
+        'storefront' => StorefrontTranslationsSeeder::class,
+        'checkout' => CheckoutTranslationsSeeder::class,
+        'validation' => ValidationTranslationsSeeder::class,
+    ];
+
+    public function handle(): int
+    {
+        $dryRun = (bool) $this->option('dry-run');
+        $total = 0;
+
+        foreach (self::SEEDERS as $group => $seederClass) {
+            $file = realpath((new ReflectionClass($seederClass))->getFileName());
+
+            if (! $dryRun && str_contains($file, '/vendor/')) {
+                $this->error("{$file} is an installed copy, not your ../boboko-core checkout.");
+                $this->line('Switch to local mode first (bin/core-mode local), or use --dry-run.');
+
+                return self::FAILURE;
+            }
+
+            $known = (new ReflectionMethod($seederClass, 'lines'))->invoke(new $seederClass);
+
+            $missing = LanguageLine::query()
+                ->where('group', $group)
+                ->whereNotIn('key', array_keys($known))
+                ->orderBy('key')
+                ->get();
+
+            if ($missing->isEmpty()) {
+                $this->line("{$group}: nothing missing");
+
+                continue;
+            }
+
+            $entries = '';
+
+            foreach ($missing as $line) {
+                $en = $line->text['en'] ?? '';
+                $el = $line->text['el'] ?? '';
+
+                if ($en === '' || $el === '') {
+                    $this->warn("  {$group}.{$line->key} has no ".($en === '' ? 'English' : 'Greek').' text — added empty, fill it in');
+                }
+
+                $entries .= $this->entry($line->key, $en, $el);
+                $this->info("  + {$group}.{$line->key}");
+            }
+
+            $total += $missing->count();
+
+            if (! $dryRun && ! $this->append($file, $entries)) {
+                return self::FAILURE;
+            }
+        }
+
+        $this->newLine();
+        $this->line($dryRun
+            ? "{$total} line(s) would be added."
+            : "{$total} line(s) added — move them into the right section and commit core.");
+
+        return self::SUCCESS;
+    }
+
+    /**
+     * One lines() entry in the seeders' own style: single line when short,
+     * split over several lines when long.
+     */
+    private function entry(string $key, string $en, string $el): string
+    {
+        [$key, $en, $el] = array_map(fn (string $value) => var_export($value, true), [$key, $en, $el]);
+
+        $single = "            {$key} => [{$en}, {$el}],\n";
+
+        if (mb_strlen($single) <= 120) {
+            return $single;
+        }
+
+        return "            {$key} => [\n                {$en},\n                {$el},\n            ],\n";
+    }
+
+    /**
+     * Inserts the entries right before the closing `];` of lines(), then
+     * lints the file and restores the original if the result doesn't parse.
+     */
+    private function append(string $file, string $entries): bool
+    {
+        $original = file_get_contents($file);
+        $method = strpos($original, 'function lines(): array');
+        $close = $method === false ? false : strpos($original, "\n        ];\n    }", $method);
+
+        if ($close === false) {
+            $this->error("Couldn't find the end of lines() in {$file} — add these by hand.");
+
+            return false;
+        }
+
+        $before = rtrim(substr($original, 0, $close));
+
+        // The last existing entry doesn't always have a trailing comma.
+        if (! str_ends_with($before, ',') && ! str_ends_with($before, '[')) {
+            $before .= ',';
+        }
+
+        $updated = $before
+            ."\n\n            // ── Pulled from the database (boboko:translations:pull) — move into the right section ──\n"
+            .$entries
+            .substr($original, $close + 1);
+
+        file_put_contents($file, $updated);
+
+        exec(PHP_BINARY.' -l '.escapeshellarg($file).' 2>&1', $output, $exitCode);
+
+        if ($exitCode !== 0) {
+            file_put_contents($file, $original);
+            $this->error("Writing {$file} produced invalid PHP — restored the original:");
+            $this->line(implode("\n", $output));
+
+            return false;
+        }
+
+        return true;
+    }
+}

src/CorePlugin.php

@@ -150,7 +150,7 @@ class CorePlugin implements Plugin
         });
 
         LunarStaff::addActivitylogExcept([
-            'otp_code',
+            'otp_code_hash',
             'otp_expires_at',
             'password',
             'remember_token',

src/Customer/Privacy/CustomerDataProvider.php

@@ -115,7 +115,7 @@ class CustomerDataProvider implements PersonalDataProvider
             // secret tied to an identity that no longer exists here — clear
             // it alongside name/email rather than leaving it to expire on
             // its own 10-minute window.
-            'otp_code' => null,
+            'otp_code_hash' => null,
             'otp_expires_at' => null,
             'otp_attempts' => 0,
         ]);

src/Customer/Services/CustomerEmailChangeService.php

@@ -23,7 +23,7 @@ use Modules\Core\Customer\Exceptions\InvalidEmailChangeCodeException;
  * hash of the code, expiry, wrong-guess count) lives on the user's own
  * row (see the migration adding pending_email/pending_email_code_hash/
  * pending_email_expires_at/pending_email_attempts) — the same convention
- * Auth\Services\UserOtpService's otp_code/otp_expires_at/otp_attempts
+ * Auth\Services\UserOtpService's otp_code_hash/otp_expires_at/otp_attempts
  * already use — rather than the session, since a code arrives by email
  * and is often opened on a different device/session than the one that
  * requested it; a session-scoped pending change couldn't be confirmed

src/Localization/Database/Seeders/StorefrontTranslationsSeeder.php

@@ -98,6 +98,14 @@ class StorefrontTranslationsSeeder extends Seeder
             'pagination.previous' => ['Previous page', 'Προηγούμενη σελίδα'],
             'pagination.page' => ['Page :page', 'Σελίδα :page'],
 
+            // ── Error pages ─────────────────────────────────────────────
+            'errors.404_title' => ['Page not found', 'Η σελίδα δεν βρέθηκε'],
+            'errors.404_text' => [
+                'The page you are looking for does not exist or has been moved.',
+                'Η σελίδα που αναζητάς δεν υπάρχει ή έχει μετακινηθεί.',
+            ],
+            'errors.back_home' => ['Back to home', 'Επιστροφή στην αρχική'],
+
             // ── Reviews ─────────────────────────────────────────────────
             'review.rating' => ['Rating', 'Βαθμολογία'],
             'review.write_label' => ['Write a review', 'Γράψε μια αξιολόγηση'],

src/Providers/LocalizationServiceProvider.php

@@ -5,6 +5,7 @@ namespace Modules\Core\Providers;
 use Illuminate\Support\Facades\Event;
 use Illuminate\Support\ServiceProvider;
 use Lunar\Models\Language;
+use Modules\Core\Command\PullTranslationsCommand;
 use Modules\Core\Localization\Events\LanguageCreated;
 use Modules\Core\Localization\Events\LanguageDeleted;
 use Modules\Core\Localization\Events\LanguageUpdated;
@@ -46,5 +47,9 @@ class LocalizationServiceProvider extends ServiceProvider
         }
 
         Event::listen(LanguageUpdated::class, MigrateTranslationsForRenamedLanguage::class);
+
+        if ($this->app->runningInConsole()) {
+            $this->commands([PullTranslationsCommand::class]);
+        }
     }
 }