mirror of
https://github.com/Memo-2023/mana-monorepo.git
synced 2026-05-18 22:01:24 +02:00
M1 of docs/plans/wardrobe-module.md — pure data layer + backend plumbing, zero UI (that's M2). A user can now hold a digital wardrobe per space: brand merch, club Trikots, family Kleiderschrank, team Kostüme, practice Dresscode, and personal closet all live as separate pools under the same Dexie tables, space-scoped like tags/scenes/agents after Phase 2c. Data model — two tables, no join: - wardrobeGarments (Dexie v41): single clothing items / accessories. Indexed on `category` + `createdAt` + `isArchived`. Encrypted: name/brand/color/size/material/tags/notes. Plaintext: category, mediaIds, counters, timestamps — all indexed or structural. `mediaIds[0]` is the primary photo used for try-on; additional ids are alternate views (back, detail) for M7. - wardrobeOutfits (Dexie v41): named compositions referencing garment ids. Encrypted: name/description/tags. Plaintext: garmentIds (FK array), occasion (closed enum — useful for undecrypted filtering), season, booleans, lastTryOn snapshot. - picture.images gains `wardrobeOutfitId?: string | null` as a plaintext back-reference. Try-on results land in the Picture gallery like any other generation; the outfit detail view queries them via this id rather than maintaining a third table. Space scope: - `wardrobe` added to all five explicit allowlists in shared-types/ spaces.ts (personal is wildcard, no edit needed). Each space type gets a one-line comment explaining the real-world use case. - App registry: `wardrobe` entry in shared-branding/mana-apps.ts with a rose→fuchsia gradient icon (T-shirt on hanger silhouette), color #e11d48, tier 'beta', status 'beta'. - Module registry: wardrobeModuleConfig imported + appended to MODULE_CONFIGS so SYNC_APP_MAP picks it up automatically. Backend: - MAX_REFERENCE_IMAGES bumped 4 → 8 in picture/generate-with- reference (plus the client-side default in ReferenceImagePicker). Justified with a comment: face + body + top + bottom + shoes + outerwear + 2 accessories = 8. Cost doesn't scale with ref count (OpenAI bills per output), so the bump is a pure capability expansion with no credit-side risk. - New POST /api/v1/wardrobe/garments/upload wraps uploadImageToMedia with app='wardrobe'. Registered under /api/v1/wardrobe in index.ts. Pattern 1:1 with the profile/me-images/upload endpoint; tier-gating falls out of wardrobe NOT being in RESOURCE_MODULES (tier='guest' works — consistent with picture's plain CRUD). Stores emit domain events (WardrobeGarmentAdded, WardrobeOutfitCreated, WardrobeOutfitTryOn, etc.) so later mana-ai missions can observe activity without polling. No UI in this commit. M2 (Garments-Grundlayer) wires the route + grid + upload-zone; M3 the Outfit composer; M4 the Try-On integration. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
84 lines
2.8 KiB
TypeScript
84 lines
2.8 KiB
TypeScript
import type { BlockSpec } from './types';
|
|
import { heroBlockSpec } from './hero';
|
|
import { richTextBlockSpec } from './richText';
|
|
import { spacerBlockSpec } from './spacer';
|
|
import { imageBlockSpec } from './image';
|
|
import { ctaBlockSpec } from './cta';
|
|
import { faqBlockSpec } from './faq';
|
|
import { columnsBlockSpec } from './columns';
|
|
import { galleryBlockSpec } from './gallery';
|
|
import { formBlockSpec } from './form';
|
|
import { moduleEmbedBlockSpec } from './moduleEmbed';
|
|
import { analyticsBlockSpec } from './analytics';
|
|
|
|
/**
|
|
* The block registry — single source of truth for every block type the
|
|
* website builder knows about. Editor insert palette, renderer, inspector,
|
|
* schema validation, and future AI tools all consume this map.
|
|
*
|
|
* Adding a new block = create a folder under `src/{type}/`, export a
|
|
* `BlockSpec` from its index, and list it here.
|
|
*/
|
|
export const BLOCK_SPECS: readonly BlockSpec<unknown>[] = [
|
|
heroBlockSpec,
|
|
richTextBlockSpec,
|
|
ctaBlockSpec,
|
|
imageBlockSpec,
|
|
galleryBlockSpec,
|
|
faqBlockSpec,
|
|
formBlockSpec,
|
|
moduleEmbedBlockSpec,
|
|
analyticsBlockSpec,
|
|
columnsBlockSpec,
|
|
spacerBlockSpec,
|
|
] as unknown as readonly BlockSpec<unknown>[];
|
|
|
|
const BY_TYPE: Record<string, BlockSpec<unknown>> = (() => {
|
|
const map: Record<string, BlockSpec<unknown>> = {};
|
|
for (const spec of BLOCK_SPECS) {
|
|
if (map[spec.type]) {
|
|
throw new Error(`[website-blocks] duplicate block type "${spec.type}"`);
|
|
}
|
|
map[spec.type] = spec as BlockSpec<unknown>;
|
|
}
|
|
return map;
|
|
})();
|
|
|
|
export function getBlockSpec(type: string): BlockSpec<unknown> | undefined {
|
|
return BY_TYPE[type];
|
|
}
|
|
|
|
export function requireBlockSpec(type: string): BlockSpec<unknown> {
|
|
const spec = BY_TYPE[type];
|
|
if (!spec) throw new Error(`[website-blocks] unknown block type "${type}"`);
|
|
return spec;
|
|
}
|
|
|
|
export function getAllBlockSpecs(): readonly BlockSpec<unknown>[] {
|
|
return BLOCK_SPECS;
|
|
}
|
|
|
|
/**
|
|
* Validate props against a block type's schema. Returns the parsed props
|
|
* (with defaults applied) on success, or throws with the Zod error.
|
|
*/
|
|
export function validateBlockProps(type: string, props: unknown): unknown {
|
|
const spec = requireBlockSpec(type);
|
|
return spec.schema.parse(props);
|
|
}
|
|
|
|
/**
|
|
* Safe-validate: returns `{ success, data, error }` without throwing.
|
|
* Used at boundaries (submit endpoint, snapshot builder) where we want
|
|
* to collect all errors rather than fail on the first one.
|
|
*/
|
|
export function safeValidateBlockProps(
|
|
type: string,
|
|
props: unknown
|
|
): { success: true; data: unknown } | { success: false; error: unknown } {
|
|
const spec = getBlockSpec(type);
|
|
if (!spec) return { success: false, error: new Error(`Unknown block type "${type}"`) };
|
|
const parsed = spec.schema.safeParse(props);
|
|
if (parsed.success) return { success: true, data: parsed.data };
|
|
return { success: false, error: parsed.error };
|
|
}
|