4861990551
Milestone 1 of the Static Pages Module sprint. - StaticPageConfig / ContentPage / ContentPageBootstrapInput gain: explicit editable route (defaults from slug, independently overridable), enabled (master on/off), status: 'draft'|'published' (per-page publish lifecycle, independent of the whole-bootstrap draft/publish cycle), customTemplate, heroImage/thumbnail/gallery, and seo.robots. - ContentPageService: normalizePage/normalizePages default missing enabled/status to enabled+published so existing bootstrap data never gets silently un-published; only the editor's createPage() opts a brand-new page into 'draft'. Legacy array-format pages get the same treatment. - resolvePage now returns null (storefront 404) for a disabled or draft page, regardless of whether the surrounding bootstrap itself is published - affects the storefront static-page route AND the auto-generated footer nav group (both go through this same resolver), which is the correct behavior. - validatePages extended: duplicateRoutes (route can now diverge from slug), invalidHtml, invalidSeo (canonical/ogImage URL shape, known robots tokens). - New schema/validators/primitives.validateHtml: stack-based tag-balance check (void/self-closing elements skipped, comments stripped). Caught and fixed a real bug during its own spec run: the initial implementation popped the stack back to the nearest matching ancestor on a mismatched closing tag, which silently swallowed a genuinely unclosed inner tag instead of flagging it - now a closing tag must match the top of the stack exactly. - toBootstrapRecord serializes the new fields; visible mirrors enabled so any reader of the older field name stays truthful. - Specs: content-page.service.spec.ts (new), primitives.spec.ts (validateHtml). Gate: tsc --noEmit, npm test (57/57), arch:check, build all green. Co-Authored-By: Claude Opus 4.8 <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.