821a1c6ba8
Renamed the experience consistently to Marketplace Builder everywhere visible (page title/subtitle, breadcrumbs, sidebar, dashboard quick action/shortcut copy) - internal ProjectEditor class/selector names kept as-is to avoid regressions. builder.title/subtitle no longer say 'bootstrap-config editing surface' to end users. New business-oriented IA (builder-groups.model.ts): 12 existing ProjectEditorSectionIds regrouped into 8 groups (Marketplace, Branding and Design, Homepage, Content, Languages, Marketplace Features, Navigation and Search, Preview) - every existing section mapped to exactly one group, none dropped, no group points at a page that doesn't exist. New Builder landing page at /edit (was a redirect straight into the General form): readiness percent, recommended next step, one overview card per group (purpose + real complete/in-progress/not-started/unknown status, icon+text never color-alone), a Marketplace Readiness checklist, quick links. All derived from real facade/schema signals (required-field fill state, modifiedSections, staticPages, catalog counts via BackofficeDataService) or explicitly marked unknown (the "preview reviewed" check has no tracking - shown as unknown, never guessed). Section pages (/edit/:section) now share one consistent header: breadcrumb (Builder > Group > Section), draft/published + modified badges, and a contextual help panel (what is this / where visible / what happens if you skip it) sourced per group. Sidebar nav rewritten as grouped, icon-led sections with per-section and per-group status indicators; layout converted from a top pill-tab bar to a responsive sidebar (desktop 280px, tablet 72px icon rail, mobile drawer with Escape-to-close), matching the Sprint 1 admin shell pattern. Section form components themselves untouched. Routes: 'edit' is now its own landing route instead of redirecting to 'edit/general'; /builder and /project-editor redirect to 'edit'. Sprint 1/2 destinations that pointed at edit/general now point at the new edit landing page. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Marketplace Frontend
Angular marketplace frontend for the client demonstration. The app uses standalone components, signals, runtime branding/configuration, and a production build optimized for the current marketplace experience.
Features
- Responsive marketplace storefront
- Category browsing and product detail pages
- Search and shopping cart flows
- Telegram login integration
- Payment handoff through the existing backend contract
- Runtime branding and configuration loading
- PWA manifest and service worker configuration
Development
Install dependencies:
npm install
Start the local development server:
npm start
Build for production:
npm run build
The production build is written to dist/dexarmarket/.
Project Structure
src/
├── app/
│ ├── components/ # Shared storefront components
│ ├── core/ # Runtime, config, guards, providers, interceptors
│ ├── dynamic-renderer/ # Page, section, and widget rendering pipeline
│ ├── facades/ # Runtime, website, builder, and backoffice facades
│ ├── pages/ # Storefront, info, legal, cart, search, and item pages
│ ├── services/ # API, cart, auth, SEO, Telegram, and language services
│ └── widgets/ # Dynamic renderer widgets
├── assets/mock/ # Local mock configuration and catalog data
├── environments/ # Development and production environment settings
└── styles/ # Shared global styles and themes
Useful Checks
npm run build
npm run arch:check
Notes
- Authentication and payment integrations are intentionally left on their existing contracts.
- Renderer and runtime architecture should remain stable during demo preparation.
- Client-facing content should avoid placeholder names, mock labels, and temporary routes.