baldart 4.98.2 → 4.98.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +8 -0
- package/VERSION +1 -1
- package/package.json +1 -1
- package/src/commands/configure.js +9 -1
package/CHANGELOG.md
CHANGED
|
@@ -5,6 +5,14 @@ All notable changes to BALDART will be documented in this file.
|
|
|
5
5
|
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
|
|
6
6
|
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
|
|
7
7
|
|
|
8
|
+
## [4.98.3] - 2026-07-02
|
|
9
|
+
|
|
10
|
+
**Bugfix: `baldart update` re-flags `multi_tenant_theming` as a "new config key" on every run.** A user reported the schema-drift detector nagging `⚠ New config keys in this version: multi_tenant_theming` at every `baldart update`, even after configuring it. Root cause: `multi_tenant_theming` was the **only** `features.*` key whose autodetected default was hardcoded `null` (`configure.js`), because there is no on-disk signal for per-tenant theming. `mergePreserving` fills it to `false` from the template, but the **non-interactive** configure branch strips every feature whose *detected* value is `null` (the "always-ask, never-assume" contract) — so a `--non-interactive` / `update --auto` / CI / auto-flow configure wrote a config **without** the key, and `update`'s drift detector (`update.js`) then re-flagged it as new on every subsequent run. The interactive path persisted it, so it appeared to "stick sometimes then forget" — a single auto flow in between re-dropped it.
|
|
11
|
+
|
|
12
|
+
- `src/commands/configure.js`: `detected.features.multi_tenant_theming` default `null → false`. Safe because **every** consumer (`ui-design`, `prd`, `bug`, `code-reviewer`, `/design-review`, …) gates on `features.multi_tenant_theming === true` — so `false` and absent are semantically identical (no skill prompts at use-time when it is absent), and the always-ask contract does not practically apply to this key. Now non-interactive configure WRITES `false` (matching the template), keeping it out of the null-strip, so the detector never re-flags it.
|
|
13
|
+
|
|
14
|
+
**PATCH** — one-line detection-default fix, no behavior change for skills (they check `=== true`), no new surface, no install-layout change. **Codex parity: portable** — `configure.js` is the shared CLI installer that writes `baldart.config.yml` for both runtimes; nothing runtime-specific. **Not a NEW `baldart.config.yml` key** (the key already exists end-to-end) → the schema-change propagation rule does NOT apply.
|
|
15
|
+
|
|
8
16
|
## [4.98.2] - 2026-07-02
|
|
9
17
|
|
|
10
18
|
**Negative guard: the codebase-understanding step is `codebase-architect`, not the generic built-in search agent.** A third live session — a data-wiring task (replace a hardcoded `"unità"` label with the real unit-of-measure in an order-wizard `ProductRow`) — delegated the code-path trace to the built-in `Explore` agent instead of `codebase-architect`, bypassing the profile engine, Reuse Analysis, Canonical Evidence, and the Return Contract. Diagnosed carefully (and deliberately *not* over-fitted): this was **not** a `PROFILE=ui` miss — the task's substance is data/logic wiring (product → UoM → loader → label), whose fitting profile is `feature`, not `ui`; the profile axis was left untouched. The real deviation was on the **agent-selection** axis, and it matches the recurring v4.97.1 shape: a positive mandate ("invoke `codebase-architect`") with no explicit "and NOT the generic explorer" guard (the existing `AGENTS.md` "never auto-route to a generic agent" rule is scoped to the *failure-fallback* case, not the initial choice).
|
package/VERSION
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
4.98.
|
|
1
|
+
4.98.3
|
package/package.json
CHANGED
|
@@ -532,7 +532,15 @@ function detect(cwd = process.cwd()) {
|
|
|
532
532
|
},
|
|
533
533
|
features: {
|
|
534
534
|
has_design_system: hasDesignSystem,
|
|
535
|
-
|
|
535
|
+
// Not autodetectable (no on-disk signal for per-tenant theming), but every
|
|
536
|
+
// consumer gates on `=== true`, so `false` and absent are semantically
|
|
537
|
+
// identical — no skill prompts at use-time when it is absent. Defaulting to
|
|
538
|
+
// `false` (matching the template) instead of `null` keeps it OUT of the
|
|
539
|
+
// non-interactive strip below (which drops null-detected keys), so a
|
|
540
|
+
// `--non-interactive`/`--auto`/CI configure actually WRITES the key. With
|
|
541
|
+
// null it was stripped every time, and `baldart update`'s schema-drift
|
|
542
|
+
// detector then re-flagged it as a "new config key" on every run.
|
|
543
|
+
multi_tenant_theming: false,
|
|
536
544
|
has_api_docs: !!(apiSchemas || openapiSpec || graphqlSchema || apiIndex || apiDocsDirPopulated),
|
|
537
545
|
has_backlog: countMatches('backlog', /\.ya?ml$/) > 0,
|
|
538
546
|
has_adrs: countMatches('docs/decisions', /^ADR-.*\.md$/) > 0,
|