Pre-launch theme system audit found multiple parallel layers in themes.css
(--theme-X full hsl strings, --X partial shadcn aliases, --color-X populated
by runtime store with raw channels) plus dead-code companion files. The
inconsistency caused light-mode regressions when scoped-CSS consumers
wrote `var(--color-X)` standalone — the variable holds raw HSL channels
which is invalid as a color value, browser fell back to inherited (white).
Rewrite to one consistent layer:
- Source of truth: --color-X defined as raw HSL channels (e.g.
`0 0% 17%`) in :root, .dark, and all variant [data-theme="..."]
blocks. Matches the format the runtime store
(@mana/shared-theme/src/utils.ts) writes, eliminating the
static-fallback-vs-runtime mismatch and the corresponding flash
of unstyled content on hydration.
- @theme inline uses self-reference + Tailwind v4 <alpha-value>
placeholder so utility classes generate correctly AND opacity
modifiers work: `text-foreground/50` → `hsl(var(--color-foreground) / 0.5)`.
- @layer components (.btn-primary, .card, .badge, etc.) wraps
var(--color-X) refs with hsl() — they were broken in light mode
too for the same reason.
Convention going forward (also documented in the file header):
1. Markup: use Tailwind utility classes (text-foreground, bg-card, …)
2. Scoped CSS: hsl(var(--color-X)) — always wrap with hsl()
3. NEVER raw var(--color-X) in CSS — that's the bug pattern
Net file: 692 → 580 LOC. Single source layer, no indirection.
Also delete dead companion files (zero imports anywhere):
- tailwind-v4.css (had broken self-reference, never imported)
- theme-variables.css (legacy hex-based palette)
- components.css (legacy component utilities)
- index.js / preset.js / colors.js (Tailwind v3 preset format,
irrelevant under Tailwind v4)
package.json exports map shrinks accordingly to just `./themes.css`.
Consumers using `hsl(var(--color-X))` (~379 files across mana-web,
manavoxel-web, arcade-web) keep working unchanged — the public API
name `--color-X` is preserved. Only the broken pattern `var(--color-X)`
(~61 files) needs a follow-up sweep, handled in a separate commit.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
3.8 KiB
Memoro
AI-powered voice recording + memo management. Memoro is a hybrid: its frontend was consolidated into the unified Mana web app, but its backend was kept as standalone services (Hono + Supabase) because of the audio-processing pipeline and the legacy Supabase Storage bucket layout.
Where things live
| Surface | Path | Notes |
|---|---|---|
| Web frontend (local-first, in unified Mana app) | apps/mana/apps/web/src/lib/modules/memoro/ |
Same module pattern as every other module — Dexie collections, Svelte 5 stores, runes UI. Reachable via /memoro route in mana.how. |
| Native mobile app | apps/memoro/apps/mobile/ |
React Native + Expo SDK 55. Talks directly to memoro-server (NOT to mana.how). Build via EAS, see apps/mobile/eas.json. |
| Backend compute | apps/memoro/apps/server/ (@memoro/server) |
Hono + Bun. Handles memo CRUD, transcription callbacks, spaces, invites, credits, settings, cleanup, meetings. Still uses Supabase for some legacy state. Deployed as memoro-server container. |
| Audio processing | apps/memoro/apps/audio-server/ |
Separate Hono+Bun service for audio uploads + transcoding. Deployed as memoro-audio-server container. |
| Landing page | apps/memoro/apps/landing/ |
Astro static landing → Cloudflare Pages |
Why memoro is not (yet) in apps/api
Most consolidated products migrated their compute routes into
apps/api/src/modules/{name}/. Memoro stayed standalone because:
- Audio pipeline. The audio-server runs background transcoding/
upload jobs that don't fit the request-response shape of
apps/api. - Legacy Supabase coupling. Memo and storage records still live
in Supabase tables (
storage.objects, RLS policies onmemos). Migrating to mana_platform was descoped in the consolidation sprint. - Three deploy targets.
memoro-server,memoro-audio-server, and the mobile app all need to coordinate. Easier to evolve as one unit while migration is in flight.
A future cleanup item is to either fold the routes into apps/api
(once Supabase is gone) or document this exception explicitly in the
root architecture overview.
Production deployment
Both backends are part of docker-compose.macmini.yml:
memoro-server (apps/memoro/apps/server) — main backend
memoro-audio-server (apps/memoro/apps/audio-server) — audio worker
The mobile app builds via EAS — not part of the monorepo CI.
Known issues / cleanup items
@mana/notify-clientis imported byapps/memoro/apps/server/src/lib/notify.ts:6but NOT declared as a dependency inapps/memoro/apps/server/package.json. Currently works via hoisted node_modules but should either be added as a workspace dep or replaced with a direct call tomana-notify. Tracked indocs/REFACTORING_AUDIT_2026_04.mditems #29.apps/memoro/apps/serverstill pulls@supabase/supabase-js— not a bug, but flagged as a dependency to remove once Supabase migration completes.- No
apps/memoro/apps/web— was removed during the consolidation. The old SvelteKit "companion web app" lives now underapps/mana/apps/web/src/lib/modules/memoro/.
For monorepo-wide patterns
See root CLAUDE.md for the overall architecture and
apps/mana/CLAUDE.md for the unified web app's
module pattern (which the memoro frontend follows).
The previous 459-line "Memoro repository overview" describing memoro as
a standalone monorepo with mana-middleware and a bespoke auth bridge
was deleted in the audit cleanup of 2026-04-09. It pre-dated the
integration into the Mana monorepo and described an architecture that
no longer exists. Pre-consolidation reference is in git history.