refactor(cli): rename sm console script to smpy

Renames the framework's CLI binary from `sm` to `smpy` to free the
short name and avoid collisions with other globally-installed `sm`
tools (e.g. `.NET` `sm`).

- Entry point: `framework/cli/pyproject.toml` `sm` → `smpy` (kept
  the `simple-module` alias).
- All docstrings, comments, READMEs, Makefile targets, generated-
  file headers, host UI strings, locale entries, skill packs, and
  documentation (guides, references, release notes, historical
  plans + specs) updated to reference `smpy`.
- Stale `sm-users` / `sm-settings` script references (removed
  during the earlier standalone-CLI migration) rewritten to the
  current `smpy users` / `smpy settings` plugin form in user-
  facing docs and module docstrings.
- Followup from /simplify review: Landing and Doctor pages no
  longer claim `smpy install / migrate / dev / doctor` — those
  are `make` targets, not subcommands.

Author: antosubash

.github/workflows/pr.yml

@@ -96,7 +96,7 @@ jobs:
           node-version: ${{ env.NODE_VERSION }}
           cache: "npm"
       # Need uv too — pages.ts imports ./modules.generated, which is
-      # produced by `sm gen-pages` from the installed Python modules.
+      # produced by `smpy gen-pages` from the installed Python modules.
       - uses: astral-sh/setup-uv@v8.0.0
         with:
           enable-cache: true

CHANGELOG.md

@@ -31,7 +31,7 @@ Initial public release. All 12 Python packages publish to PyPI and all 3 JS pack
 
 ### Added
 
-- `sm new <app>` CLI generator (shipped via the `simple_module_cli` PyPI distribution) scaffolding a working app with `users + dashboard + permissions` pre-wired.
+- `smpy new <app>` CLI generator (shipped via the `simple_module_cli` PyPI distribution) scaffolding a working app with `users + dashboard + permissions` pre-wired.
 - PyPI Trusted Publishing workflow (`.github/workflows/release.yml`) for zero-secret releases.
 - npm Trusted Publishing for all three JS packages.
 

Makefile

@@ -25,12 +25,12 @@ dev-ui:
 
 # Regenerate host/client_app/modules.{manifest.json,generated.ts,generated.css} from installed modules.
 gen-pages:
-	uv run --project host sm host gen-pages --host-dir=host/client_app
+	uv run --project host smpy host gen-pages --host-dir=host/client_app
 
 # Install JS deps declared by installed modules into host/client_app/node_modules.
 # Wheel-installed modules need this; in-repo workspace modules do not.
 sync-module-deps:
-	uv run --project host sm host sync-js-deps --host-client-app=host/client_app
+	uv run --project host smpy host sync-js-deps --host-client-app=host/client_app
 
 # Build
 build:

README.md

@@ -15,7 +15,7 @@ A modular-monolith framework for Python. Each feature lives in its own self-cont
 If you want to **build an app on simple_module**, not hack on the framework itself:
 
 ```bash
-uvx --from simple_module_cli sm new my-app
+uvx --from simple_module_cli smpy new my-app
 cd my-app
 make dev
 ```
@@ -45,7 +45,7 @@ make migrate
 make dev
 ```
 
-Hit `http://localhost:8000` — you land on the public page. `/users/login` is the email+password login, `/dashboard/` is the authenticated home, and `/dashboard/doctor` is the admin-only "sm doctor" panel (static checks, migrations, dev server, modules).
+Hit `http://localhost:8000` — you land on the public page. `/users/login` is the email+password login, `/dashboard/` is the authenticated home, and `/dashboard/doctor` is the admin-only "smpy doctor" panel (static checks, migrations, dev server, modules).
 
 ## Create a new module
 
@@ -121,7 +121,7 @@ Power users can still override the following bootstrap knobs via env if needed:
 All module-level settings — users, SMTP, Celery broker, file storage backend, etc. — live in the admin UI. After upgrading an existing deployment, run once:
 
 ```bash
-uv run sm settings import-from-env
+uv run smpy settings import-from-env
 ```
 
 to seed DB overrides from the current `SM_*` environment.
@@ -163,7 +163,7 @@ The 300-line file cap (enforced by CI) usually pushes you to factor row-level co
 Either use the CLI:
 
 ```bash
-uv run sm users create-admin --email admin@example.com --password changeme
+uv run smpy users create-admin --email admin@example.com --password changeme
 ```
 
 Or let the app bootstrap it automatically on first boot by setting env vars **before** running `make migrate && make dev`:

docs/database/migrations.md

@@ -46,7 +46,7 @@ uv run alembic downgrade orders@base     # back to the state before the orders m
 
 ## First migration of a new module
 
-When you scaffold a module with `sm create-module`, the *first* autogenerate revision produces a file that needs this marker added by hand:
+When you scaffold a module with `smpy create-module`, the *first* autogenerate revision produces a file that needs this marker added by hand:
 
 ```python
 # migrations/versions/XXXX_add_orders_tables.py
@@ -108,7 +108,7 @@ If `invoices` has an FK to `orders.order.id`:
 
 - Alembic will emit `ADD CONSTRAINT` in the invoices table's migration.
 - The migration that creates `invoices_invoice` must come **after** the one that creates `orders_order` in linear history.
-- `sm create-module` + `uv run alembic revision --autogenerate` handle this naturally as long as `depends_on` is correct in `ModuleMeta`.
+- `smpy create-module` + `uv run alembic revision --autogenerate` handle this naturally as long as `depends_on` is correct in `ModuleMeta`.
 
 On Postgres, cross-schema FKs work natively (`orders.order.id ← invoices.invoice.order_id`).
 

docs/e2e-testing.md

@@ -29,7 +29,7 @@ make dev                        # FastAPI on :8000 + Vite on :5050
 Create the first admin user (needed for e2e auth):
 
 ```bash
-uv run sm-users create-admin --email admin@example.com --password admin
+uv run smpy users create-admin --email admin@example.com --password admin
 ```
 
 Or set `SM_USERS_BOOTSTRAP_EMAIL` / `SM_USERS_BOOTSTRAP_PASSWORD` in `.env`
@@ -48,7 +48,7 @@ When you write e2e tests, read these environment variables (all optional):
 | Variable       | Default                   | Notes                                                        |
 | -------------- | ------------------------- | ------------------------------------------------------------ |
 | `E2E_BASE_URL` | `http://localhost:8000`   | Where the FastAPI host is listening.                         |
-| `E2E_USERNAME` | `admin@example.com`       | Email of the admin user created via `sm-users create-admin`. |
+| `E2E_USERNAME` | `admin@example.com`       | Email of the admin user created via `smpy users create-admin`. |
 | `E2E_PASSWORD` | `admin`                   | Password of the above admin user.                            |
 | `SM_USERS_VERIFICATION_TOKEN_SECRET` | `dev-verify-token-secret-change-me` | Must match the running server's value so locally-minted invite tokens are accepted. |
 

docs/framework-conventions.md

@@ -20,7 +20,7 @@ modules/<name>/
     └── pages/                # *.tsx — auto-discovered by Vite
 ```
 
-Scaffold a fresh module with `sm create-module <name> --dest modules/<name>` — it generates all of the above. Then run `uv add ./modules/<name>` to register it on your app.
+Scaffold a fresh module with `smpy create-module <name> --dest modules/<name>` — it generates all of the above. Then run `uv add ./modules/<name>` to register it on your app.
 
 ## ModuleMeta
 
@@ -296,7 +296,7 @@ class OrdersModule(ModuleBase):
         return {"orders": Path(str(importlib.resources.files(__package__) / "locales"))}
 ```
 
-`sm create-module` scaffolds this method and a matching `locales/en.json` automatically.
+`smpy create-module` scaffolds this method and a matching `locales/en.json` automatically.
 
 ### Key naming
 

docs/framework/i18n.md

@@ -26,7 +26,7 @@ class OrdersModule(ModuleBase):
         }
 ```
 
-The key (`"orders"`) is the **namespace** — it prefixes every key in the files. `sm create-module` scaffolds this method and a starter `en.json` automatically.
+The key (`"orders"`) is the **namespace** — it prefixes every key in the files. `smpy create-module` scaffolds this method and a starter `en.json` automatically.
 
 ## Key naming
 

docs/framework/settings.md

@@ -133,7 +133,7 @@ Values are keyed by `<namespace>.<key>`. Conventional namespace is the module na
 Existing deployments that used env vars for module settings should run once:
 
 ```bash
-uv run sm-settings import-from-env
+uv run smpy settings import-from-env
 ```
 
 This reads the current environment, looks up keys the settings service knows about, and writes overrides into the DB. Idempotent — skips keys that already have a DB override. After running, you can remove those env vars from deployment config.

docs/guide/configuration.md

@@ -75,7 +75,7 @@ Prefix `SM_BG_TASKS_*`. The defaults in `docker-compose.yml` already set these s
 After upgrading from an older deployment, import existing `SM_*` values into the DB settings store once:
 
 ```bash
-uv run sm-settings import-from-env
+uv run smpy settings import-from-env
 ```
 
 This is idempotent — it only seeds keys that don't have a DB override yet.