branding/README's "Integration with NixOS deployment" section now
describes the actual lib.mkWebapp API + the per-host call site, with
a ready-to-paste server-deploy snippet. Also documents the pnpm_10
pin, sharp/autoPatchelfHook handling, and CI=true bypass — anchors
that surface in error logs and benefit from being grep-able.
CLAUDE.md's NixOS deployment paragraph stops calling lib.mkWebapp a
future TODO and points at the API directly.
Adds a `nix build` recipe (default + impure brand override) for local
sanity-checking.
Part of aiolabs/webapp#97.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
branding/README.md is the deployer contract:
- Directory layout, source format constraints (SVG > PNG ≥ 1024),
brand.json schema, per-standalone override resolution order
- BRAND_DIR / BRAND_APP usage, generator pipeline walkthrough
- Pointer to issue #95 + the NixOS Phase 2 integration
webapp CLAUDE.md gains a Brand Kit section describing the moving
parts (vite-branding.ts, @brand alias, brandAssetsPlugin,
public/icons/ gitignore, per-app override path) so future sessions
on this repo know the convention without grepping.
Adds BRAND_DIR / BRAND_APP to the Environment Variables example.
Workspace ~/dev/CLAUDE.md note about "brand changes don't need
flake.lock bump" deferred to Phase 2 (server-deploy migration) —
that's when the workflow becomes reality.
Part of aiolabs/webapp#95.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Why
The module was named `activities` originally to avoid colliding with Nostr's `Event` type. In practice that defense added friction without preventing confusion — the backend extension is named `events`, NIP-52 calls them "Calendar Events", and the UI already displayed "Events". The collision with `nostr-tools` `Event` is handled cleanly by the existing `import { Event as NostrEvent }` alias pattern (already in 5 files inside the module). Renaming collapses the 4-way mismatch into one consistent term.
Separately, deployments needed per-instance app names. `VITE_APP_NAME` was already plumbed per-standalone via NixOS `services.webapp-standalones.<app>.displayName` (e.g. cfaun shipped `"Sortir"`, now rebranded to `"Bouge"`), but nothing in the standalone consumed it — PWA manifest, HTML title, and runtime branding were all hardcoded. This PR wires the env through every app-name display point so any deploy can flip `displayName = "Bouge"` (or anything) and pick up the brand end-to-end.
## What
Nine commits on the branch:
1. **`refactor(events): rename activities module to events`** — 70-file rename. `src/modules/activities/` → `src/modules/events/`, `src/activities-app/` → `src/events-app/`, types/services/composables/views/components/store renamed (`Activity`→`Event`, `Activities`→`Events`). Routes `/activities/*` → `/events/*`; the legacy `/events` (ticketing management) moves to `/my-events` so `/events` belongs to the canonical feed. DI tokens `ACTIVITIES_*` → `EVENTS_*`. i18n namespace renamed; English domain strings updated, French/Spanish title key realigned. npm scripts `:activities` → `:events`. Build output `dist-activities/` → `dist-events/`.
2. **`feat(events): wire VITE_APP_NAME through PWA manifest, HTML, runtime`** — PWA manifest `name`/`short_name` template from `process.env.VITE_APP_NAME` with fallback `'Events'`. `events.html` uses Vite's `%VITE_APP_NAME%` substitution. `src/events-app/app.ts` + `main.ts` runtime brand string drives console logs, offline notification, and `acceptTokenFromUrl()`. `events.title` route meta sources from VITE_APP_NAME. `.env.example` updated with per-standalone scoping notes.
3. **`docs(events): update activities→events references`** — `docs/nostr-patterns/*.md` "Canonical: src/modules/activities/composables/useRSVP.ts" anchors point at renamed paths. CLAUDE.md Payment Rails Pattern section updated.
4. **`fix(events): drop lowercase from PWA description brand name`** — minor casing fix caught during verification.
5. **`fix(events): use domain noun in description, not brand name`** — manifest + HTML description switched from `"Discover ${BRAND} near you"` to static `"Discover events near you"`. Description is about *what* the app does, not the brand.
6. **`chore(events): scrub leftover sortir/activities references`** — nginx.conf.example, package.json (concurrently process label + `build:demo` BASE_PATH), router-helpers comment, useMarket comment, and vite.events.config.ts doc-comment.
7. **`refactor(events): conditional brand in console label, tighten docs`** — adds `APP_LABEL` next to `APP_NAME` in `events-app/app.ts`. Reads as `Events` on unbranded builds and `Events (Bouge)` (etc.) when `VITE_APP_NAME` is set to anything other than "Events" (case-insensitive). Used by all four console messages; `acceptTokenFromUrl` keeps the raw `APP_NAME` (it's a token-namespace identifier, not display copy). Also collapses the redundant "cfaun sets X; future deployments can override (e.g. X)" doc-comment.
8. **`i18n(events): finish activité/actividad → événement/evento sweep`** — completes the i18n rename in fr.ts and es.ts (search placeholders, favorites prompts, settings prompt) and fixes five gender-agreement errors that came along with the masculine `événement`/`evento` switch (French: `Aucune ... trouvée`→`Aucun ... trouvé`, `préférées`→`préférés`, `d'une ... la sauvegarder`→`d'un ... le sauvegarder`; Spanish: `favoritas`→`favoritos`, `guardarla`→`guardarlo`).
9. **`chore(events): finish sortir → bouge sweep in .env.example`** — four remaining doc-comment refs in `.env.example` (cfaun branding, ticket-scanner comment, section header, subdomain-mode URL example).
## Cross-repo coordination
This PR has matching changes already pushed to two other repos. They have to land in a coordinated bump because the names are tightly coupled.
- **`aiolabs/webapp-module` main** — commit `9d82016`. Renames `hubActivitiesUrl` → `hubEventsUrl` and `VITE_HUB_ACTIVITIES_URL` → `VITE_HUB_EVENTS_URL`. No backwards-compat shim.
- **`aiolabs/server-deploy` main** — commits `f15e1eb`, `bf4698b`, `d46a520`:
- `standalones.nix` `apps.events` uses `build:events` / `dist-events` / `events.html`; `hubUrlOption` maps `events → "hubEventsUrl"`; comment + cfaun-as-example doc switched from sortir/Sortir to bouge/Bouge.
- `hosts/cfaun/default.nix` rebranded: `subdomain = "bouge"` + `displayName = "Bouge"`. (Native-French feedback retired the "Sortir" branding as awkward.)
- `hosts/atio/default.nix` stale "activities app" comment dropped (atio's `displayName = "Eventos"` config is unchanged).
server-deploy's `flake.lock` still pins the OLD webapp + OLD webapp-module, so nix builds from server-deploy main will fail until the bumps. Suggested order after this PR merges to `dev`: one server-deploy commit that does `nix flake lock --update-input webapp-module` + `--update-input webapp-demo` together. DNS for `bouge.ariege.io` needs to point at the cfaun host before the deploy lands.
## Verification
- `pnpm typecheck` — clean ✓
- `pnpm build:events` (default) — `dist-events/manifest.webmanifest` has `name: "Events"`, description "Discover events near you" ✓
- `VITE_APP_NAME=Bouge pnpm build:events` — `name: "Bouge"`, HTML title "Bouge", console label resolves to `Events (Bouge)` ✓
- Cross-repo grep sweep: no `Sortir`/`sortir`/`activities`/`Activities` references in events-module scope. (Domain false positives — "Market Activity" in market dashboard, "time-based activities" in nostr-feed content filters, "Activity Lifecycle Kills" in CLAUDE.md mobile-browser docs — are unrelated and intentionally left alone.)
Not verified in-browser (no GUI in this session) — needs a manual smoke at `app.ariege.io/bouge/` once the coordinated flake bump lands on cfaun. Watch for: feed loads, `/events/calendar`, `/events/map`, `/events/favorites`, `/events/:id` routes work; "My Events" appears in the user dropdown and `/my-events` shows the management page; PWA install prompt shows "Bouge".
## Out of scope (deferred)
- Backend extension rename — `aiolabs/events` is already named correctly.
- Nix standalone attribute name — `services.webapp-standalones.events` is already correct.
- Overriding domain-noun strings ("Your event was created", RSVP labels) — those stay locale-driven; `VITE_APP_NAME` covers app-name only.
- Backwards-compat redirects from `/activities/*` to `/events/*` — pre-launch, public URL was `/sortir/` (path-mode) or `sortir.ariege.io` (subdomain-mode), never `/activities/`. No external bookmarks to preserve. (`sortir.ariege.io` → `bouge.ariege.io` is a separate decision; up to the deploy operator whether to keep a 301 for word-of-mouth referrers.)
Reviewed-on: #94
Activities is the first module to mix Lightning + fiat rails; restaurant
and marketplace will follow. Extract the cross-cutting bits to the base
module so the next adoption is a wiring exercise:
- useFiatProviders: reactive `User.fiat_providers` (today the same list
for organizer + buyer because LNbits configures providers globally),
plus `providerMeta()` for label/icon hints.
- usePriceConversion: `convert()` + reactive `useLivePreview()` over
the existing `/api/v1/conversion` endpoint, 60s cache, null on
transient failure.
- PaymentMethodSelector: buyer-side rail picker. `PaymentMethod.id`
enumerates rails (`lightning | fiat | cash | internal | …`) with
`provider` for the fiat case so a multi-provider instance shows one
button per provider instead of a bare "Fiat" catch-all.
- FiatToggleField: organizer-side switch + conditional fiat-currency
dropdown. Auto-disables with a setup-instructions tooltip when the
user has no providers; silently mirrors fiat_currency to a non-sat
price denomination to keep the backend payload consistent.
- PriceConversionPreview: muted "≈ X.XX USD" line for surfaces where
the price denomination differs from the chosen rail's currency.
LnbitsAPI.getConversion wraps the conversion endpoint so the composable
goes through the existing API service rather than raw fetch. CLAUDE.md
gains a "Payment rails pattern" section documenting the canonical
vocabulary ("Price currency" / "Fiat currency" / "Payment method" /
"Also accept fiat" — bare "Currency" and "Pay in fiat" are banned in
payment-context UI labels) and the fiat-providers-are-global note.
The pre-existing `prvkey` comment on User picks up an inline allowlist
marker so the secret scanner stops flagging this file on every commit.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Refines project documentation to reflect recent architectural changes and coding standards.
Adds detailed explanations of the BaseService pattern, module structure, and JavaScript best practices to enhance developer understanding and consistency.
Clarifies CSS styling guidelines, emphasizing semantic classes for theme-aware styling.
Includes critical bug prevention techniques related to JavaScript falsy values and correct usage of the nullish coalescing operator.
Updates build configuration details, environment variable requirements, and mobile browser workaround strategies.
- Updated the quantity assignment in the useMarket composable to use nullish coalescing (??) instead of logical OR (||). This change ensures that a quantity of 0 is preserved, preventing unintended defaults when productData.quantity is explicitly set to 0.
These changes improve the accuracy of product quantity handling in the market module.
- Introduced guidelines for handling complex object reactivity in Vue, addressing common issues such as input components not updating and computed properties not recalculating.
- Provided solutions including using Object.assign for object reactivity, dynamic keys for component re-renders, and safe navigation with fallbacks.
- Included practical examples to illustrate the application of these patterns in real scenarios, enhancing developer understanding of Vue's reactivity system.
- Expanded CLAUDE.md to include detailed information about the new Wallet Module, emphasizing its functionality for Lightning wallet management and real-time balance updates.
- Updated README.md to reflect the modular architecture, key features, and real-time wallet capabilities, including WebSocket configuration and connection management.
- Added sections on WebSocket real-time features, including automatic balance updates, live notifications, and battery optimization strategies.
These enhancements improve the clarity and accessibility of the wallet integration documentation, aiding developers in implementation and usage.
- Introduced a comprehensive module development checklist to ensure consistency and quality in module implementation.
- Added critical service and module installation requirements, emphasizing proper service initialization, dependency management, and configuration usage.
- Included common mistakes to avoid during module development to guide developers in best practices.
These updates enhance the documentation for module development, promoting better adherence to standards and improving overall code quality.
- Introduce critical guidelines for using Shadcn/UI form components in conjunction with vee-validate for form handling.
- Provide detailed examples for required form setup, template structure, and key requirements to ensure proper validation and accessibility.
- Emphasize the importance of type safety using Zod schema for validation and correct form handling practices.
These updates aim to standardize form implementations across the application, enhancing consistency and maintainability.
- Delete Nostr client hub and associated files, including the Nostr store, to eliminate unused functionality.
- Update service tokens and dependency injections to reflect the removal of Nostr client services.
- Adjust notification settings in NotificationSettings.vue to prepare for future implementation of notifications.
- Create comprehensive documentation for the new VisibilityService, detailing its purpose, core concepts, and architecture.
- Include an integration guide for module developers, outlining best practices for registering services and handling app visibility changes.
- Add example code snippets for implementing visibility management in various service types, ensuring clarity and ease of use.
- Introduce a troubleshooting section to address common issues and provide debugging tips for developers.
- Enhance the VisibilityService integration guide with real-world examples to illustrate practical usage scenarios.
- Update architecture overview to emphasize the modular structure of the application.
- Introduce detailed sections on core modules, module configuration, and the plugin manager.
- Outline the dependency injection pattern for service management across modules.
- Add development guidelines for module structure, plugin patterns, and service integration.
- Emphasize the importance of using dependency injection for cross-module service access.