Gesamte Mono-Repo des Baukastens (alle apps/clients, examples/tests und packages)
dh_heyart
vor 6 Std. 1f1c89f5d6dd8325a46f2434bf9ac67a55c826fd
ROADMAP.md
@@ -14,8 +14,6 @@
      legacy `merge` / `readMergedLayoutConfig` untouched.
      *(Optional: add a baukasten test-case folder under `data/test/json` and run `npm run debug:json-merge`.)*
## To do (suggested order)
### Runtime
- [x] **B. Merged-config endpoint.** Additive baukasten branch in `WebUIController.readLayoutConfig`
      (`webuiProject === "baukasten"` → `BaukastenService.readConfigurations(refs)` →
@@ -33,6 +31,7 @@
      `clientDir/index.html` when `webuiProject === "baukasten"`; `getReadFilePath` resolves
      `/webui-content/{token}/t/baukasten/…` assets under `clientDir` (with a traversal guard).
      Reuses the existing routes; path-only `style/*` + `tokenWorker.js` unchanged (per-customer).
### Supporting
- [x] **E. Real configuration data (starter).** Added a real `14243/public/layout1.json` (root
@@ -90,14 +89,15 @@
      `baukasten` project (so it had been 500-ing). The client already applies it via the shared
      `TemplateLoaderService` (`construction:initialize` → fetch `themeConfig` → `:root` color vars +
      `template`/`config-id` options), so no client change. *(Server-only JS — furnplan_web reload.)*
      *(Follow-up implemented in M2.)*
      *(Follow-up implemented in M2. Later superseded for baukasten by **T**: the runtime theme now rides in
      `layout.json` via `construction:initialize`, and `readThemeConfig` is the AUC-editor source only.)*
- [x] **M2. AUC theme editor for baukasten.** Restructured `article-url-configurator.ts`
      `onWebUIModeDropDownChanged` so the `themeConfig` fetch + `buildWebUIThemeConfig` run once for every
      webui project incl. baukasten (removing the baukasten early-return / code duplication). Baukasten now
      shows the theme editor (`#webUIThemeOptions`), so `webui_theme_config` is UI-editable and round-trips
      via the existing `getWebUIThemeConfigJson`/`prepareSave` path; category filters stay modular-only.
      Together with M this gives baukasten full per-customer theming parity. *(AUC rebuild — user's build.)*
      *(Per-layout theming was explored afterwards and shelved — see **T** under "Shelved / parked".)*
      *(Per-layout theming was explored afterwards; initially shelved, later **shipped** — see **T**.)*
- [x] **N. Move `client_logic` into the baukasten monorepo.** Relocated the Vite client source into
      `baukasten/apps/client` (new `apps/` workspace glob; package `@dh-software/baukasten-client`), registered
      in `package.json` + `pnpm-workspace.yaml` (added `autoInstallPeers` + the client's dev-link `overrides`,
@@ -132,9 +132,9 @@
      `baukasten-data/`) was archived under `baukasten/old/`, now **deleted** after verification. *(Done.)*
- [x] **Q. Test real layout 1 & 2 configurations & fix bugs.** Real layout_1 & layout_2 configs load and
      render correctly on the baukasten base (light-DOM adapter + merge graft, full UI). Verified working.
- [ ] **R. `fv-layout`: rework the component CSS.** Revisit the `:host` / `.layout-container` / `.node`
      styling, possibly dropping the inner `.layout-container` wrapper so the grid lives directly on the
      host (simpler tree, fewer wrappers).
- [x] **R. `fv-layout`: rework the component CSS.** **User-owned** — implementing + committing directly.
      Revisit the `:host` / `.layout-container` / `.node` styling, possibly dropping the inner
      `.layout-container` wrapper so the grid lives directly on the host (simpler tree, fewer wrappers).
- [x] **G. End-to-end verification** — pick + order → save → reopen (restored) → open link → client loads,
      fetches merged config, renders. Verified. *(Save-As parity broke out as **G2** — decided: kept as-is.)*
- [x] **G2. Save-As / Template-As parity — decided: keep as-is.** Save-As/Template-As
@@ -147,32 +147,43 @@
      *consistent* with the pre-existing modular Save-As, not a regression. **Left unchanged.** If ever fixed,
      fix both together: carry the top-level fields through the Save-As handlers → `UseCaseConfigurationModel.create`
      body → the server `create` template. (Normal *Save* works — it PUTs the whole `openedConfiguration` to `update`.)
- [ ] **H. Packaging / release** — publish `@dh-software/baukasten` + `@dh-software/baukasten-config-ui`
      to `npm.furnco.de` (replace the `file:` deps); propagate the `furncloud-models` schema change;
      mirror all furnplan_web/furncloud-models edits into the released `_furnview` bundle.
- [x] **H. Packaging / release** — `@dh-software/baukasten` + `@dh-software/baukasten-config-ui` (+ types /
      config-reader / permissions) **published to `npm.furnco.de`**. Follow-ups that ride on the publish (do
      when needed): swap furnplan_web's two `file:` deps → published `^` ranges; commit + push the
      `furncloud-models` `baukastenConfigurations` schema edit and re-pin furnplan_web to it; mirror the
      furnplan_web/furncloud-models edits + the baukasten client/configs into the `_furnview` bundle.
### Per-layout theme — SHIPPED
- [x] **T. Per-layout theme config.** Implemented via the previously-preferred-but-shelved approach (3):
      **the theme rides in `layout.json` and the client applies it.** `template.service` (webui-core) now takes
      the theme from the `construction:initialize` event payload (the merged `config/layout.json`, which embeds
      `layout.theme`) instead of a separate `themeConfig` fetch, and `WebUIController.readLayoutConfig`'s
      baukasten branch bakes per-customer overrides into it —
      `layout.theme = _.merge(layout.theme, JSON.parse(configuration.webui_theme_config))`, guarded **inside
      `if (layout)`** so it never derefs an undefined merge result (empty `baukastenConfigurations` / service
      not ready → `readMergedBaukastenConfig` returns `undefined`), with the `JSON.parse` in its own try/catch.
      `readThemeConfig` is now the **AUC-editor's source only**: its `getConfiguration(req, false)` moved inside
      a `try/catch` (fixes the earlier server crash on the no-`a` theme fetch) and it returns the raw
      `layout.theme` — the editor merges `webui_theme_config` client-side in `buildWebUIThemeConfig`. The empty
      fallback `{colors:{},template:{}}` is intentional (base theme defaults removed from the dist configs).
      Modular configs (no embedded `theme`) still fall back to the separate `themeConfig` fetch, so legacy
      theming is unaffected. Supersedes M's "client fetches `themeConfig`" note for baukasten.
      *(webui-core `template.service` change = user's build/publish; server JS = furnplan_web reload.)*
## To do (suggested order)
### Future / large
- [ ] **I. Baukasten "configurator"** — tool/UI to generate & edit customer `fileinfo.json` + config
      JSONs (so DAs don't hand-edit files).
      JSONs (so DAs don't hand-edit files). **Direction (concrete sub-tasks TBD together):** extract & rework
      the *necessary* parts of the current AUC into separate packages — consumed by the AUC itself for now —
      that the Baukasten configurator then reuses to configure the existing AUC settings from the Baukasten UI,
      cleaned up to be understandable by an end-user.
- [ ] **J. Retire the old DB-backed 3-layer system** once Baukasten fully replaces it (migration/cleanup).
  - [ ] restructure furnview-components into:
      1. legacy-components (components that have been entirely replaced by others)
      2. furnview-components (current components with styleVars and no dh-components internals)
      3. baukasten-components (prefix bk-, fv-components that are reworked to use dh-components and no longer support stylevars, styled using material design 3)
- [ ] **S. Revisit `isStoreMember` after the global store-system rework.** The current resolver reads
      `FurncloudCredential.StoreTree.Stores[].kdnr_dh`; once the planned global rework of the
      store/membership model lands, re-align it to the new shape/semantics.
### Shelved / parked
- [ ] **T. Per-layout theme config (SHELVED).** The theme schema (`theme.json`) was per-layout historically
      (`bin_layout_1/config` vs `bin_layout_2/config`), but baukasten has one shared client folder, so M's
      shared `clientDir/config/theme.json` can't serve both. No *easy, self-contained* approach was found, so
      it's parked. **Interim: M stands** — runtime + AUC editor both use the single shared `theme.json`, which
      is fine while layout_1/layout_2 themes are effectively identical (they are today); revisit when they truly
      diverge, or fold into **N** (moving `client_logic` into the monorepo may make a client-side approach
      self-contained). Approaches considered & rejected: (1) `readThemeConfig` re-reads the base config's
      `theme` — fragile config re-read + base-first assumption; (2) full merge in `readThemeConfig` + shared
      helper + `readLayoutConfig` strip + AUC `?a=<id>` — too many changes; (3) theme rides in `layout.json`,
      client applies it — cleanest, but spreads across two published webui-core packages (`webui-api`:
      `event/events.ts`, `service/template.service.ts`; `webui-configuration-parser`:
      `types/construction.types.ts`, `service/construction.service.ts`) + a `webui_theme_config` bake-in in
      `readLayoutConfig`, needing a webui-core build/publish + client rebuild. Key facts for the revisit: the
      merge preserves an embedded top-level `theme`; `getConfiguration` needs `?a=` (the AUC theme fetch lacks
      it); the AUC editor merges `webui_theme_config` client-side while the runtime does it server-side;
      `client_logic` consumes webui-core as versioned deps.