feat(wren-ui): align modeling assistant with Cloud route workflows#2199
Open
N2XK wants to merge 105 commits intoCanner:mainfrom
Open
feat(wren-ui): align modeling assistant with Cloud route workflows#2199N2XK wants to merge 105 commits intoCanner:mainfrom
N2XK wants to merge 105 commits intoCanner:mainfrom
Conversation
added 30 commits
April 2, 2026 14:34
This checkpoint captures the current WrenAI rebuild state: workspace and knowledge-base runtime scaffolding, skill-runner integration, skill-first ask orchestration, and the UI/runtime scope plumbing needed to render skill results inside the existing thread experience. Constraint: Keep wren-engine remote and avoid engine-side refactors in this phase Constraint: Preserve existing TEXT_TO_SQL behavior while introducing skill-first fallback logic Rejected: Delay UI skill rendering until persistence is redesigned | blocked end-to-end validation of the new ask flow Confidence: medium Scope-risk: broad Reversibility: clean Directive: If skill results move from askingTask-only to thread_response persistence, update the GraphQL/client rendering path and polling rules together Tested: PYTHONPATH=. poetry run pytest tests/pytest/core/test_skill_contract.py tests/pytest/core/test_skill_runner.py tests/pytest/test_config.py tests/pytest/services/test_ask_skill_runner.py -q Tested: yarn test src/apollo/server/adaptors/tests/wrenAIAdaptor.test.ts src/apollo/server/utils/tests/askContext.test.ts src/apollo/server/services/tests/askingTaskTracker.test.ts src/apollo/server/services/tests/askingService.test.ts src/apollo/server/resolvers/tests/askingResolver.test.ts src/hooks/useAskPrompt.test.ts --runInBand Not-tested: Full wren-ui typecheck still has pre-existing failures (vega-lite typings, SiderLayout props, graphql context drift)
This local checkpoint captures the in-flight runtime identity, pgvector, connector/skill, dashboard, and deepagents work so OMX team can fork clean worktrees from a stable base while continuing the remaining closeout lanes. Constraint: omx team requires a clean leader workspace before creating worker worktrees Rejected: git stash before launch | workers would lose the in-progress codebase state needed for closeout Confidence: medium Scope-risk: broad Reversibility: clean Directive: Treat this as a local orchestration checkpoint; follow-up commits should stay focused by lane Tested: Recent targeted pgvector/sql_pairs/provider regressions before checkpoint Not-tested: Full monorepo verification at checkpoint commit
The tmux/notify hooks updated tracked OMX state immediately after the checkpoint commit, which blocked omx team from creating clean worker worktrees. Constraint: omx team refuses to start when tracked runtime-state files are dirty Rejected: stash runtime-state files | hook writes would immediately dirty the leader workspace again Confidence: high Scope-risk: narrow Reversibility: clean Directive: OMX runtime artifacts should eventually be ignored or isolated from product code to avoid launch friction Tested: git status clean enough for subsequent omx team preflight Not-tested: Long-running hook churn during active team execution
Golden ask regression now exercises deepagents as the primary runtime for every baseline case and asserts the legacy fallback metadata for non-skill flows. This keeps closeout verification aligned with the runtime flip without touching worker-1's implementation files. Constraint: Worker-1 already owns the config/default-runtime implementation files Rejected: Modify test_ask_skill_runner.py here | would overlap worker-1's active write set Confidence: high Scope-risk: narrow Directive: Keep golden regression on the deepagents entry path so future runtime flips preserve fallback evidence Tested: lsp diagnostics on modified file; ruff check on modified file; compileall for src and updated test; pytest tests/pytest/services/test_ask_golden_regression.py tests/pytest/services/test_ask_skill_runner.py tests/pytest/test_config.py tests/pytest/core/test_trace_compare.py tests/pytest/test_utils.py
This switches the service defaults to deepagents while keeping the legacy path available as the existing fallback. The regression coverage now proves both the default deepagents primary path and the preserved legacy fallback path so the closeout flip is anchored by focused ask-path evidence. Constraint: Keep the diff inside the Wren AI service ask-runtime scope for Lane1 closeout Rejected: Broaden into UI/runtime bridge cleanup | assigned to a different lane Rejected: Rework tool-router fallback semantics | unnecessary for the default-mode flip Confidence: high Scope-risk: narrow Directive: Keep explicit legacy mode support until rollout evidence says the fallback can be retired Tested: ruff check on modified files; compileall for src plus focused tests; pytest test_config + test_ask_skill_runner + test_ask_golden_regression Not-tested: full end-to-end service boot against external providers
Document the reviewed P1-09/P1-11/runtime-identity state, capture focused verification results, and record the remaining cutover/default-mode gap plus unrelated UI typecheck noise for integration readout. Constraint: Keep the diff limited to closeout documentation for the assigned review lane Rejected: Update the existing context snapshot in place | preserve the original intake snapshot and add a dated review artifact instead Confidence: high Scope-risk: narrow Tested: focused pytest ask/runtime suite; focused jest runtime identity suite; runtime identity scans; py_compile; runtimeScope.ts diagnostics Not-tested: repo-wide UI typecheck still fails in unrelated chart/home/knowledge files
Home ask, thread recommendations, and project recommendations now preserve\nruntimeScopeId end-to-end from the UI resolver layer to wren-ai-service.\nThis removes the deploy-hash fallback that was breaking local source\nacceptance, and it adds short docs for the minimal infra + source startup\nflow used during verification.\n\nConstraint: Worktree contains broader deproject changes, so this commit stays limited to the verified runtime-scope ask/recommendation path and local acceptance docs\nRejected: Commit the entire closeout tree together | too broad to verify atomically from the current dirty worktree\nConfidence: high\nScope-risk: moderate\nReversibility: clean\nDirective: Keep runtimeScopeId explicit from resolver to adaptor for ask and recommendation requests; do not rely on implicit deploy-hash fallback\nTested: yarn test --runInBand src/apollo/server/adaptors/tests/wrenAIAdaptor.test.ts src/apollo/server/services/tests/askingService.test.ts src/apollo/server/resolvers/tests/askingResolver.test.ts src/apollo/server/context/tests/runtimeScope.test.ts src/apollo/server/resolvers/tests/projectResolver.test.ts\nTested: yarn test --runInBand src/apollo/server/resolvers/tests/modelResolver.test.ts\nTested: yarn check-types\nTested: Manual local-source acceptance for /home?runtimeScopeId=4 ask + thread recommendation + project recommendation GraphQL checks\nNot-tested: Non-sample dataset homepage recommendation card rendering
The v1 chart API already previews SQL locally, so the UI can send that\nmaterialized dataset to ai-service instead of asking the chart service to\nresolve runtime scope and execute SQL a second time. This keeps the chart\npath aligned with runtime-scope-first protocols and trims another legacy\nbridge dependency from the route layer.\n\nConstraint: The repo is still a dirty closeout tree, so this commit is limited to the chart request contract and its verified adaptor coverage\nRejected: Keep chart generation on ai-service SQL re-execution | duplicates work and preserves an unnecessary runtime-scope dependency in the API route\nConfidence: high\nScope-risk: narrow\nReversibility: clean\nDirective: When a route already owns preview data, prefer passing data/runtimeScopeId to ai-service instead of re-resolving execution from legacy bridge fields\nTested: cd wren-ui && yarn test --runInBand src/apollo/server/adaptors/tests/wrenAIAdaptor.test.ts\nTested: cd wren-ui && yarn check-types\nNot-tested: End-to-end /api/v1/generate_vega_chart browser/manual acceptance against live infra
Eval still starts from upstream Spider/BIRD SQLite artifacts, but the
loader now resolves the effective benchmark DSN, creates the right
PostgreSQL database, maps host-side targets back onto the matching
Docker route for pgloader, and finalizes non-public schemas so host-run
eval flows can round-trip through PostgreSQL without hardcoded network
or database assumptions.
This slice also adds regression coverage, a reusable smoke script,
SQLite residual guardrails/inventory, and docs/config examples that
separate host-side published PostgreSQL addresses from container-internal
postgres:5432 usage.
Constraint: Upstream Spider/BIRD benchmark assets still arrive as SQLite files
Constraint: Host-run eval metadata uses published PostgreSQL addresses while pgloader needs a container-reachable route
Rejected: Keep importing into one hardcoded benchmark database | breaks per-catalog DSN templates and hides routing bugs
Rejected: Leave the smoke script classified as active runtime SQLite usage | contradicts the benchmark-only exception boundary
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Benchmark SQLite references are intentional eval compatibility only; keep the residual allowlist and inventory rules aligned with any future helper scripts
Tested: python -m py_compile on eval loader/test/smoke files
Tested: poetry run pytest tests/pytest/eval/test_spider_database_adapter.py tests/pytest/eval/test_pipeline_metric_config.py tests/pytest/eval/test_metrics.py tests/pytest/eval/test_evaluation_benchmark_target.py -q (28 passed)
Tested: poetry run python tools/eval_postgres_loader_smoke.py --benchmark-target 'postgresql://postgres:postgres@localhost:9432/smoke_{db_name}?schema=analytics'
Tested: bash misc/scripts/check-sqlite-residuals.sh
Tested: bash misc/scripts/inventory-sqlite-residuals.sh > docs/sqlite-residual-inventory.md
Not-tested: direct just recipe invocation in this environment (just not installed)
Not-tested: multiple PostgreSQL containers publishing the same host port
This snapshot captures the in-flight workspace/auth/governance work, the KB/settings IA cleanup, and the REST-first UI/API refactors already landed across wren-ui, wren-ai-service, and wren-engine so the next GraphQL→REST planning pass has a stable baseline to diff against. Constraint: User requested an immediate checkpoint of the current multi-package working tree before further migration planning Constraint: The branch contains coordinated changes across UI, API, service, engine, docs, and deployment assets, so splitting safely would take longer than freezing the baseline Rejected: Split the tree into multiple thematic commits first | would delay the requested checkpoint and risk reshuffling in-flight work from parallel terminals Confidence: medium Scope-risk: broad Reversibility: clean Directive: Treat this as a freeze-point commit; keep follow-up GraphQL→REST work incremental and verify Home ask flow and Modeling separately before removing Apollo surfaces Tested: git diff --cached --shortstat; staged tree review by top-level directory Not-tested: Full lint/typecheck/test matrix across the monorepo
This document captures the current runtime GraphQL inventory, the recommended migration waves, the endpoint gaps, and the Apollo retirement criteria so follow-up work can execute against one shared plan instead of rediscovering the same boundaries. Constraint: The repo still has multiple parallel workstreams, so the document had to isolate the migration plan from unrelated in-flight file changes Rejected: Fold the plan into an existing doc | would make the migration checklist harder to find and maintain as a living inventory Confidence: high Scope-risk: narrow Reversibility: clean Directive: Update this inventory whenever a GraphQL runtime entry point is removed or a new REST facade lands; keep the endpoint status column current Tested: Manual inventory cross-check against current wren-ui runtime GraphQL usage and existing src/pages/api/v1 + src/utils/*Rest.ts surfaces Not-tested: Markdown lint automation
This wave migrates the home ask flow, thread detail reads, modeling/deploy interactions, setup helpers, and related runtime bootstrap paths onto workspace-scoped REST helpers and API routes. It also removes ApolloProvider from the app shell, keeps the existing UI behavior, and updates the regression tests to assert the REST contract instead of generated GraphQL hooks. Constraint: User requested GraphQL->REST consolidation without adding dependencies Constraint: Repo-wide lint still has pre-existing failures outside the migrated files Rejected: Keep mixed Apollo/REST runtime ownership | cache drift and scope mismatch remained hard to reason about Rejected: Rewrite all generated GraphQL type references in the same wave | higher churn than needed for the runtime migration Confidence: medium Scope-risk: broad Directive: For migrated lanes, prefer REST helpers/routes over reintroducing generated Apollo hooks; only keep generated types while a REST-native shared schema is absent Tested: yarn check-types; npx jest --runInBand src/tests/pages/home/index.test.tsx src/tests/pages/modeling.test.tsx src/components/pages/modeling/form/ModelForm.test.tsx; scoped eslint over changed TS/TSX files; rg scan confirming no remaining runtime useQuery/useMutation/useApolloClient/ApolloProvider in src outside src/apollo and tests Not-tested: Full repo lint (fails on pre-existing unrelated files); full Playwright/E2E against live services
The frontend now reads and mutates through REST helpers only, with local API contracts in src/types/api.ts replacing generated GraphQL artifacts. This commit removes Apollo/codegen runtime baggage, updates the remaining tests and E2E helpers, and keeps the modeling/runtime/server support code that still backs REST endpoints. Constraint: Existing REST endpoints had to remain source-compatible while GraphQL infra was removed Rejected: Keep generated type shims beside the REST code | would preserve Apollo/codegen debt and dual maintenance Confidence: high Scope-risk: broad Reversibility: messy Directive: New UI data access should go through REST helpers plus src/types/api.ts, not revived GraphQL generators Tested: yarn check-types; yarn lint:changed --since HEAD; npx jest --runInBand src/tests/pages/home/index.test.tsx src/tests/pages/home/thread.test.tsx src/tests/pages/knowledge/index.test.tsx src/tests/pages/settings/connectors.test.tsx src/tests/pages/api-management/history.test.tsx src/components/pages/home/promptThread/ChartAnswer.test.tsx src/tests/pages/modeling.test.tsx src/components/pages/modeling/form/ModelForm.test.tsx Not-tested: next build; full Playwright E2E; ai-service integration flows
The shared dev flow now keeps custom knowledge bases workspace-scoped from bootstrap through validation. This includes dry-run SQL template validation for named params, scope-aware rule/SQL count loading on the knowledge page, project reset handling for TiDB relation/canonical-scope recovery, pgvector workspace scoping, and UI init/verify coverage for the TiDB and PostgreSQL workspaces.\n\nThe follow-up slice removes the remaining first-KB API fallback in the UI init script and proves that an empty workspace can create its first knowledge base entirely through the 3002 UI flow before continuing with datasource/model/rule/template validation. Constraint: Must use the shared dev environment on 3002/5555/9432 and avoid sqlite or ad-hoc replacement environments\nConstraint: User required pure-UI validation for workspace, knowledge-base, datasource, asset, SQL template, and analysis-rule setup\nRejected: Keep the first-KB API fallback in the init script | it hid the empty-workspace UI path the user wanted verified\nConfidence: medium\nScope-risk: moderate\nReversibility: clean\nDirective: Preserve workspace-scoped runtime selector behavior and knowledge-count refresh before changing bootstrap or setup flows again\nTested: yarn jest src/hooks/useKnowledgeRuleSqlManager.test.ts src/tests/pages/knowledge/index.test.tsx src/server/utils/tests/apiUtils.test.ts src/pages/api/tests/sql_pairs_api.test.ts src/server/controllers/tests/projectController.test.ts src/server/controllers/tests/runtimeSelectorController.test.ts src/runtime/client/tests/runtimeScope.test.ts --runInBand\nTested: poetry run pytest tests/pytest/providers/test_pgvector_provider.py\nTested: node wren-ui/tmp/ui_init_workspaces.cjs\nTested: node wren-ui/tmp/ui_verify_custom_workspaces.cjs\nTested: Manual pure-UI first knowledge-base creation on a fresh empty workspace in the shared 3002 environment\nNot-tested: Full regression outside the workspace/knowledge/custom-datasource flows
Home ask submission was navigating with the inferred ask selector even when the server created the thread under a more specific canonical runtime scope. That left thread pages reloading under partial scope, which could hide responses and prevent text answers from auto-generating after SQL completed. This change reuses the canonical runtime identity returned from thread creation when routing to the new thread, and keeps the auto-answer scheduler deterministic so cancelled timers do not poison later retries. Tests now cover both the canonical thread navigation and the auto-generate scheduling edge case. Constraint: 3002 shared dev verification must use UI-visible runtime scope behavior Rejected: Reconstruct thread scope client-side from selected KB only | drops snapshot and deploy identity Rejected: Loosen server thread-response scoping | would hide runtime-scope mismatch instead of fixing it Confidence: high Scope-risk: narrow Reversibility: clean Directive: Thread navigation after creation should prefer server-returned canonical scope over inferred client fallback Tested: yarn test src/tests/pages/home/index.test.tsx src/components/pages/home/promptThread/AnswerResult.test.ts src/utils/askingTimeouts.test.ts --runInBand; yarn check-types; node wren-ui/tmp/ui_verify_custom_workspaces_recheck.js Not-tested: Existing history-sidebar thread clicks still use workspace-scoped prefetch paths and may deserve a separate audit
History thread clicks were already runtime-aware, but hover/focus/background prefetch still fell back to the workspace-scoped selector. That could warm the thread overview cache with the wrong runtime scope before navigation.\n\nThis change centralizes history selector resolution, uses the item selector for thread href construction and overview prefetch, and adds helper coverage so selector-bearing history items keep their canonical knowledge-base scope.\n\nConstraint: History items may carry canonical runtime selectors that are narrower than the workspace fallback\nRejected: Leave prefetch workspace-scoped and rely on click refetch | wrong-scope cache warmup still happens before navigation\nConfidence: high\nScope-risk: narrow\nDirective: Keep history click and prefetch paths on the same selector source so thread scope cannot drift\nTested: cd wren-ui && yarn test src/components/reference/DolaAppShell.test.tsx src/tests/pages/home/index.test.tsx src/components/pages/home/promptThread/AnswerResult.test.ts src/utils/askingTimeouts.test.ts --runInBand\nTested: cd wren-ui && yarn check-types\nNot-tested: Manual live hover/focus regression in the 3002 UI shell
Capture the current frontend architecture assessment in one review document and one execution backlog so the upcoming refactor work can proceed from a shared baseline. The review records the major architectural issues across routing, shell composition, feature boundaries, request flows, and performance. The backlog turns those findings into staged waves with acceptance criteria and a recommended execution order. Constraint: The repository already contains many unrelated in-progress changes, so this commit isolates only the new architecture docs Rejected: Mix the docs into a broader WIP checkpoint | would couple an audit artifact to unrelated code changes Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep the review doc as the diagnostic snapshot and evolve follow-up implementation in backlog or code-specific docs instead of rewriting history Tested: Verified both markdown files exist and are staged as the only paths in this commit Not-tested: Any code changes or backlog implementation work
This snapshots the current repository state across the frontend shell refresh, knowledge workbench evolution, workspace-aware settings and connection flows, server module migration out of the legacy apollo path, deepagents and permission documentation updates, and the associated test and asset changes. The goal of this checkpoint is to preserve the meaningful application work while keeping local runtime artifacts and debugging output out of version control. The resulting commit is intentionally broad because the working tree already contained one integrated tranche of related product, architecture, and migration work spanning docs, UI, API, and tests. Constraint: The repository had a large mixed working tree, so this commit excludes local runtime state (.omc/.omx), generated screenshots, Next build artifacts, and tmp debugging output Rejected: Split this checkpoint into many retrospective commits | the existing change set is already interleaved across shared modules and route migrations Confidence: medium Scope-risk: broad Reversibility: messy Directive: Treat this as a checkpoint commit; follow-up cleanup should narrow remaining legacy aliases and further separate route, shell, and feature responsibilities Tested: pytest tests/pytest/providers/test_wren_engine.py; jest --runInBand src/components/runtimeScope/RuntimeScopeSelector.test.tsx src/hooks/useCheckOnboarding.test.ts src/components/sidebar/Modeling.test.tsx src/utils/knowledgeWorkbenchEditor.test.ts src/pages/api/tests/restApi.test.ts Not-tested: Full wren-ui lint/typecheck suite; Playwright e2e matrix; full app runtime smoke across all workspaces and connectors
Prevent common local debugging outputs and auxiliary frontend build folders from showing up as untracked noise while keeping the repository focused on source changes. This adds ignores for temporary frontend screenshots and scripts, standalone e2e build directories, local OMX helper state under wren-ui, and ad hoc output files created during manual verification. Constraint: The repo intentionally keeps some docs and planned artifacts under version control, so this ignore pass stays narrow to obviously local debug outputs Rejected: Broadly ignore all image and tmp-like paths | would risk hiding legitimate checked-in assets and fixtures Confidence: high Scope-risk: narrow Reversibility: clean Directive: If a temporary debug artifact becomes worth sharing, move it into a purpose-built docs or test fixture location instead of weakening ignore rules Tested: git status reduced to tracked OMX runtime-state noise only after restore Not-tested: Any application runtime behavior
…is snapshots the in-flight frontend architecture cleanup across route-entry re-exports, settings feature pages, request-key convergence, knowledge/home shell refactors, and the synced docs/inventory updates. The immediate goal is operational: OMX team worktree launch is blocked while the leader workspace is dirty, so this commit turns the current WIP into a resumable baseline for parallel execution.\n\nConstraint: omx team requires a clean leader workspace before it will create worker worktrees\nRejected: stash-only cleanup | would hide meaningful WIP and make later team lanes harder to diff and reconcile\nConfidence: medium\nScope-risk: broad\nReversibility: clean\nDirective: Treat this as a checkpoint baseline for team execution; keep subsequent backlog slices in smaller follow-up commits\nTested: yarn eslint on remaining settings route-entry cleanup slice; yarn jest src/tests/pages/settings/{audit,diagnostics,identity,automation,system-tasks,platform}.test.tsx --runInBand\nNot-tested: full wren-ui typecheck, broader frontend route smoke tests, e2e flows
added 25 commits
April 21, 2026 17:42
…refetch The modeling workspace was issuing a second deploy-status refetch during bootstrap, which canceled the hook's automatic request and added noise to the network timeline. The knowledge sidebar was also prefetching the diagram endpoint even though knowledge/modeling pages already fetch the diagram directly, so the extra request had little payoff. This keeps deploy-status ownership with useDeployStatusRest for initial page load, preserves explicit diagram+status refreshes for user-triggered modeling updates, and narrows knowledge prefetch to data that improves navigation without duplicating diagram fetches. Constraint: Repo has many unrelated working-tree changes; this commit stages only the targeted modeling/prefetch files Rejected: Disable deploy-status auto loading globally | would defer initial status visibility for other consumers Rejected: Keep diagram sidebar prefetch and rely on cache reuse | runtime-scoped URLs differ enough that the extra fetch often does not help Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep modeling bootstrap separate from manual refresh paths so mount does not duplicate deploy-status requests Tested: yarn test src/features/modeling/useModelingWorkspaceState.test.ts src/tests/pages/modeling.test.tsx src/hooks/useDeployStatusRest.test.ts --runInBand Tested: yarn test src/components/reference/useDolaShellSidebarPrefetch.test.tsx src/utils/runtimePagePrefetch.test.ts --runInBand Tested: yarn eslint src/features/modeling/useModelingWorkspaceState.ts src/features/modeling/useModelingWorkspaceState.test.ts src/tests/pages/modeling.test.tsx Tested: yarn eslint src/components/reference/useDolaShellSidebarPrefetch.ts src/components/reference/useDolaShellSidebarPrefetch.test.tsx src/utils/runtimePagePrefetch.ts src/utils/runtimePagePrefetch.test.ts Not-tested: Live browser network capture after the bootstrap/status change Not-tested: Full yarn check-types still fails on unrelated ChartAnswer/ChartAnswerPinModal type errors
This change fixes the dashboard grid sizing bug that pushed right-aligned cards outside their container, expands dashboard-level actions so every dashboard row can refresh and manage cache settings, and redesigns the chart pin flow to match the new lightweight interaction model: direct pin when there is only one dashboard, popover selection when there are multiple dashboards, and a focused create-and-pin modal for new dashboards. Constraint: The repository contains many unrelated in-progress changes, so this commit intentionally isolates only the dashboard and chart-pinning slice Rejected: Keep a single modal for all pin flows | too heavy for the common case and adds unnecessary choice friction Confidence: high Scope-risk: moderate Reversibility: clean Directive: Preserve the single-dashboard direct-pin path unless the dashboard model changes to require explicit target confirmation Tested: yarn check-types; targeted Jest suites for chart render, dashboard page, dashboard layout, dashboard service pin idempotency, and chart pin popover/modal flows Not-tested: Full Playwright visual regression after the latest popover sizing polish
The business-requirement docs now separate current UI import sources from archived reference material so instruction and SQL template intake is easier to execute and review.
This keeps the single-file rule/template assets as the authoritative source, adds an explicit UI import checklist, and moves older aggregate/template/generated suggested-question artifacts under an archive path. The accidental Office lock file is removed as part of the cleanup.
Constraint: The current product only supports manual UI import; there is no automated importer yet
Rejected: Keep aggregate markdown pages as active sources | duplicates authority and makes manual import ambiguous
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Use docs/业务需求/knowledge-base/{analysis-rules,sql-templates} as the only active UI import source until a scripted importer exists
Tested: Manual doc structure review
Not-tested: In-product UI import flow
…ource The docs tree had accumulated outdated planning material and an embedded PPT source workspace that no longer serves the active repo workflows. This batch moves the explicitly archived planning docs into a dated archive location and removes the obsolete PPT source subtree so the top-level docs surface stays focused on current guidance. Constraint: The user asked to archive obviously stale docs without disturbing active recent documentation Rejected: Leave stale plans in place and rely on manual search discipline | keeps docs discovery noisy and misleading Confidence: high Scope-risk: narrow Reversibility: clean Directive: Put future retired docs under docs/archive/<date>-... instead of leaving them mixed with active guidance Tested: Manual archive path and file inventory review Not-tested: External links that may still reference archived filenames
The frontend docs now reflect the current architecture baseline, the next cleanup batch, the runtime upgrade path, and the chart follow-up product direction that the recent UI work is steering toward. This keeps the architecture inventory aligned with the live repo state and consolidates runtime-upgrade guidance into current dated docs instead of spreading decisions across older drafts. Constraint: The repo still runs on the existing Pages Router + Less bridge while the upgrade path is being staged Rejected: Fold these notes into one monolithic plan document | makes verification and targeted follow-up harder Confidence: high Scope-risk: narrow Reversibility: clean Directive: Update these dated docs when repo facts materially change; do not revive older superseded drafts as the primary plan Tested: Manual doc content review against current repo state Not-tested: Automated link validation
The benchmark/eval tooling now assumes PostgreSQL execution targets instead of carrying dual SQLite and PostgreSQL loader paths. This removes the residual SQLite allowlist scripts, drops the loader smoke helper, simplifies the Spider benchmark adapter to PostgreSQL-only behavior, updates the docs/config examples, and cleans leftover sqlite-specific ignore entries from repo metadata. Constraint: The product runtime and local stack are already PostgreSQL-first, so benchmark tooling should no longer imply SQLite remains a supported execution path Rejected: Keep the SQLite compatibility layer dormant behind docs warnings | preserves dead code and stale operator guidance Confidence: high Scope-risk: moderate Reversibility: clean Directive: Do not reintroduce SQLite benchmark execution without a fresh parity plan and explicit product need Tested: poetry run pytest tests/pytest/eval/test_evaluation_benchmark_target.py tests/pytest/eval/test_pipeline_metric_config.py tests/pytest/eval/test_spider_database_adapter.py -q Not-tested: Full end-to-end benchmark execution against a real external PostgreSQL benchmark catalog
The runtime scope bootstrap path now tolerates temporary selector mismatches across the API, shared client loaders, and polling loops instead of failing fast and leaving the UI in a reload loop. This batch adds opt-in missing-scope handling for the bootstrap endpoint, retries transient runtime-scope errors in shared REST helpers, ignores stale persisted bootstrap candidates when the server returns no scope, and keeps sidebar/deploy polling dormant until selector state is ready. Constraint: Modeling, home sidebar, and deploy status all depend on runtime-scope bootstrap and were surfacing transient backend timing issues to the UI Rejected: Add bespoke retry logic in each hook | duplicates policy and makes future error handling drift Confidence: high Scope-risk: moderate Reversibility: clean Directive: Put future runtime-scope retry behavior behind shared helpers instead of new one-off polling logic Tested: yarn test --runTestsByPath src/tests/api/apiContext.test.ts src/tests/api/runtime_scope_current_api.test.ts src/hooks/homeSidebarRequests.test.ts src/hooks/runtimeSelectorStateRequest.test.ts src/hooks/usePollingRequestLoop.test.ts src/runtime/client/tests/runtimeScope.test.ts src/utils/modelingRest.test.ts Not-tested: Live browser verification against a slow-starting local runtime
Several Pages Router endpoints were still importing helper modules from sibling route files, which made reuse awkward and kept route-only code mixed with reusable server utilities. This batch relocates shared auth, platform, skills, stream, SCIM, and workspace API helpers into server/api and rewires the page handlers to import from the shared location without changing the handler surface. Constraint: The repo still uses the Pages Router, so server-side route helpers need a stable home that is not itself a route entry Rejected: Keep helper files under src/pages/api and tolerate cross-route imports | preserves coupling between route discovery and reusable server logic Confidence: high Scope-risk: narrow Reversibility: clean Directive: New reusable route helpers belong under src/server/api, not beside page handlers Tested: yarn test --findRelatedTests src/pages/api/auth/session.ts src/pages/api/v1/workspace/current.ts src/pages/api/v1/skills/marketplace.ts src/pages/api/v1/stream/ask.ts Not-tested: Full route inventory build after all remaining UI changes
The server-side ask/chart lifecycle now survives process restarts better and records more evidence when chart generation fails. This batch rehydrates unfinished asking tasks during startup, records preview and terminal diagnostics on chart detail payloads, logs final chart failures with context, and removes the stale sqlite-specific retry hint from query dry-run recovery. Constraint: Modeling and chart generation were losing visibility when background jobs restarted or failed after the initial preview step Rejected: Add diagnostics only to logs | leaves the UI and stored response payloads without failure context Confidence: high Scope-risk: moderate Reversibility: clean Directive: Keep persisted chart diagnostics small and focused on debugging signals, not full preview payloads Tested: yarn test --runTestsByPath src/server/backgrounds/tests/chartBackgroundTracker.test.ts src/server/services/tests/askingService.chartLifecycle.test.ts src/server/services/tests/askingTaskTracker.test.ts src/server/services/tests/queryService.test.ts Not-tested: End-to-end restart recovery against a live local server process
The remaining frontend runtime work is consolidated into one batch: Next is upgraded to v15, the temporary rc-component patch script is removed, legacy Less utility layers are replaced with runtime CSS foundations/utilities, compatibility routes are updated, and runtime pages move onto the shared Antd app bridge plus Antd 6 prop conventions. This also refreshes several settings/home/knowledge surfaces to use the newer component APIs, keeps route inventory metadata aligned, and preserves the legacy /api-management entry as an alias to the diagnostics page. Constraint: The app still runs on the Pages Router and must keep existing routes working while the runtime/styling bridge is narrowed Rejected: Land the Next/runtime upgrade without the UI bridge cleanups | would leave mixed styling/message patterns and make the upgrade harder to stabilize Confidence: medium Scope-risk: broad Reversibility: messy Directive: Continue deleting Less utility layers and static antd message usage instead of adding new call sites to the old patterns Tested: node scripts/check_pages_routes.mjs; yarn test --runTestsByPath src/tests/pages/home/index.test.tsx src/tests/pages/api-management/index.test.tsx src/utils/antdAppBridge.test.ts Not-tested: Full yarn lint/build/test run; manual cross-page browser QA for all touched settings and modeling flows
Two remaining views still relied on deprecated Descriptions item patterns after the runtime shell upgrade. This follow-up converts the profile summary and schedule run detail drawers to the newer items/styles API and updates the workspace schedules page test fixture so it grants the manage-schedule capability expected by the action-button assertions. Constraint: The broader runtime upgrade already moved adjacent surfaces onto Ant Design 6 APIs, so these lagging views needed the same treatment Rejected: Leave the old Descriptions usage in place until a later sweep | keeps the upgrade half-finished and breaks related tests Confidence: high Scope-risk: narrow Reversibility: clean Directive: Prefer Descriptions items/styles over legacy Item children + labelStyle/contentStyle usage on new Ant Design 6 surfaces Tested: yarn test --findRelatedTests src/features/settings/profile/ManageProfilePage.tsx src/components/pages/workspace/ScheduleRunDetailsDrawer.tsx Not-tested: Manual browser QA for the profile and workspace schedules detail drawers
A few detail drawers and related tests still used pre-upgrade Description mocks or missed small UX adjustments after the broader UI runtime modernization. This follow-up moves the API history detail drawer and schedule run drawer tests onto the Ant Design 6 Descriptions mock shape, updates the API history drawer itself to the items/styles API, and pins the dashboard workbench rail menu to bottom-right placement for more stable interaction. Constraint: The main runtime upgrade already changed adjacent drawers and dropdowns, so these stragglers needed to match the same component API contract Rejected: Leave the old test mocks and placement defaults in place | keeps the suite brittle and the workbench menu less predictable Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep new drawer tests mocking Descriptions via the items API rather than legacy Item children Tested: yarn test --runTestsByPath src/components/pages/apiManagement/DetailsDrawer.test.tsx src/components/pages/workspace/ScheduleRunDetailsDrawer.test.tsx src/tests/pages/workspace/schedules.test.tsx Not-tested: Manual dashboard workbench interaction QA
A leftover formatting-only diff remained in the SQL tab action strip after the broader UI runtime modernization. This folds the inline Space separator markup back to the repo's current formatting style so the working tree stays clean after batching the real functional changes. Constraint: The user asked for the commit queue to be cleaned up, including small residual diffs that should ship with the batch Rejected: Leave the single-file formatting diff uncommitted | keeps the tree dirty and obscures real follow-up work Confidence: high Scope-risk: narrow Reversibility: clean Directive: Run formatting cleanups together when practical so small JSX whitespace diffs do not linger after larger UI batches Tested: Manual diff review Not-tested: Automated verification (formatting-only change)
Prettier drift in the dashboard and chart answer paths was the last blocker for a clean frontend lint run. This commit limits the fix to the four eslint-flagged files so formatting is brought back in line without widening the change surface or altering behavior. Constraint: Keep the cleanup limited to the lint-blocking files only Rejected: Run prettier across the repo | too much unrelated churn for a cleanup-only pass Confidence: high Scope-risk: narrow Reversibility: clean Directive: If these files drift again, prefer a targeted prettier pass over repo-wide formatting Tested: cd wren-ui && yarn lint Tested: cd wren-ui && yarn test --runInBand src/components/pages/home/promptThread/ChartAnswer.test.tsx src/components/pages/home/promptThread/ChartAnswerPinPopover.test.tsx src/tests/pages/home/dashboard.test.tsx src/tests/pages/dashboard/index.test.tsx Not-tested: Manual dashboard and chart interaction smoke test
This batch moves the UI lane to Node 20 and Next 16, migrates ESLint from the legacy eslintrc files to flat config, and keeps the local verification path on webpack while our less/custom setup catches up. It also fixes the two lint regressions that surfaced during the upgrade and ignores local .next-* verification outputs. Constraint: Current UI runtime upgrade targets Node 20 + Next 16 across local, Docker, and CI Constraint: The less/custom Next integration still needs webpack for dev/build/e2e startup Rejected: Keep Node 18 and Next 15 | leaves the UI lane behind the current runtime target Rejected: Keep legacy eslintrc files under ESLint 9 | flat config is the stable path for this upgrade Confidence: high Scope-risk: moderate Directive: Re-check Next 16 turbopack and less compatibility before removing the explicit --webpack flags Tested: yarn install --mode=skip-build --immutable Tested: yarn lint Tested: yarn test src/hooks/useKnowledgeRuntimeDataSync.test.ts --runInBand Tested: node scripts/check_pages_routes.mjs Tested: NEXT_DIST_DIR=.next-verify yarn build Not-tested: Full Jest suite Not-tested: Playwright e2e suite
The UI upgrade still had two kinds of failures: the old Less/Webpack path no longer matched the Next 16 runtime, and the React 19 type + test runtime exposed background singleton leaks that made Jest noisy and unreliable. This keeps the migration shippable by moving the shell styling onto CSS, aligning the Next config and runtime shims with the newer toolchain, updating React-facing types and deprecated Antd props, and adding explicit test cleanup so the upgraded stack can pass verification without stray trackers or database handles. Constraint: Next 16 no longer fits the previous next-with-less and forced --webpack setup used by the UI shell Constraint: React 19 tightened ref and element typing across shared UI components and tests Rejected: Commit the whole working tree | unrelated docs, OMX artifacts, and schedule work are still in progress Confidence: high Scope-risk: moderate Reversibility: clean Directive: Keep Jest scoped to *.test.* files and preserve explicit singleton cleanup when touching background trackers or shared service bootstrapping Tested: cd wren-ui && yarn check-types Tested: cd wren-ui && yarn lint Tested: cd wren-ui && yarn test --runInBand Not-tested: Playwright E2E against the upgraded stack Not-tested: Manual UI smoke test after restoring unrelated unstaged work
The upgraded UI still had one unstable path around scheduled dashboard refreshes: operators could not inspect runs or edit plans cleanly from the new shell, and repeated updates could leave duplicate dashboard refresh jobs behind. This hardens the schedule control plane by giving the workspace and settings routes a dedicated task UI, keeping schedule actions scoped to the active workspace, preventing duplicate submits from the dashboard entry point, and repairing duplicate dashboard refresh records with migration and service-level recovery logic. Constraint: Existing environments may already contain duplicate dashboard_refresh jobs that must be merged before uniqueness can be enforced Constraint: Workspace schedule actions must stay bound to workspace scope even when a richer runtime selector is present Rejected: Rely on manual database cleanup | not durable for shared or already-drifted environments Rejected: Fix duplicate failures only in the client | race conditions can still create unique conflicts on the server Confidence: high Scope-risk: moderate Reversibility: clean Directive: Preserve the dashboard_refresh uniqueness guarantee in both the migration and ScheduleService recovery path when changing schedule lifecycle behavior Tested: cd wren-ui && yarn check-types Tested: cd wren-ui && yarn lint Tested: cd wren-ui && yarn test --runInBand Not-tested: Manual browser verification of the new schedule drawers and tabs after restoring unrelated unstaged work
The OMX runtime files had drifted away from the current workspace state: the mission ledger was still empty, the tmux hook still pointed at an old pane, and stale PPT export artifacts were left behind after the latest run. This records the finished mission metadata for the current session, updates the hook target to the active pane, and removes obsolete rendered deck outputs so the tracked OMX state matches the current environment snapshot. Constraint: The user explicitly asked to checkpoint only .omx and .omc changes before touching the remaining repo work Constraint: .omx is ignore-listed, so tracked runtime files must be updated without broad restaging of other ignored content Rejected: Leave runtime artifacts uncommitted | would keep tracked OMX state inconsistent with the current session snapshot Confidence: high Scope-risk: narrow Reversibility: clean Directive: Treat these runtime files as session bookkeeping; keep future commits scoped so OMX state changes do not accidentally pull in unrelated product code Tested: git diff --cached --name-only for .omx/.omc scope verification Not-tested: Application lint, typecheck, or Jest (runtime metadata only)
This consolidates the recent settings work into one coherent UI normalization pass. The settings shell, profile, connectors, diagnostics, permissions, platform management, skills, system tasks, and users pages now lean more consistently on standard AntD layout primitives and shared shell patterns instead of page-specific wrapper structures. It also captures the final permissions/platform-permissions cleanup and adds regression coverage for the canonical platform permissions page so the normalized shell stays stable. Constraint: Existing repo-wide typecheck is noisy because of an unrelated home/thread workbench issue Rejected: Split this lane into many micro-commits | would fragment one cohesive settings normalization pass Confidence: high Scope-risk: moderate Reversibility: clean Directive: Keep future settings page work aligned with ConsoleShellLayout and standard AntD layout primitives before introducing custom wrappers Tested: yarn eslint src/features/settings src/tests/pages/settings src/components/reference/ConsoleShellLayout.tsx Tested: yarn test src/tests/pages/settings --runInBand Tested: File-level TypeScript diagnostics for touched settings tail files Not-tested: Full repo yarn check-types (blocked by unrelated home/thread issue)
…board tiles Dashboard source links live inside draggable grid items, so a normal click can be swallowed before the navigation handler runs. This change stops pointer-start propagation on the source-thread action and adds a focused regression test that proves drag prevention does not block the intended navigation callback. Constraint: Dashboard tiles must keep react-grid-layout drag behavior for the rest of the card Rejected: Disable tile dragging around the action area entirely | too broad for a button-sized interaction bug Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep source-thread actions isolated from tile-level drag listeners when adjusting dashboard card interactions Tested: yarn test --runInBand src/components/pages/home/dashboardGrid/DashboardGridPinnedItem.test.tsx Tested: yarn test --runInBand src/tests/pages/home/dashboard.test.tsx Not-tested: Full dashboard browser drag interaction after future grid-library upgrades
This lands the documented Cloud Home alignment work across the home thread UI, dashboard/pinning runtime plumbing, response lineage contracts, and the supporting ask/chart service paths. The result is the new dual-surface thread experience with contextual follow-up aids, independent chart follow-up responses, richer thinking-step handling, runtime-aware dashboard behavior, and the docs/tests that describe and lock the behavior. Constraint: The Cloud-aligned interaction model must preserve replay/history compatibility while supporting runtime-scoped ask, chart, pin-to-dashboard, and schedule flows Rejected: Keep chart interactions embedded inside answer cards/tabs only | conflicts with the dual-surface workbench and Cloud follow-up model Rejected: Execute contextual aid chips immediately | Cloud verification showed draft-to-composer semantics are the safer canonical behavior Confidence: medium Scope-risk: broad Reversibility: messy Directive: Treat selected response, active workbench artifact, and response lineage as one contract when extending future thread/workbench interactions Tested: yarn test --runInBand src/components/pages/home/dashboardGrid/DashboardGridPinnedItem.test.tsx Tested: yarn test --runInBand src/tests/pages/home/dashboard.test.tsx Tested: SCENARIO=sample-hr node tmp/ui-real-e2e-cloud-home.mjs Tested: SCENARIO=tidb-business node tmp/ui-real-e2e-cloud-home.mjs Not-tested: Full repo-wide UI/AI-service test matrix after bundling all staged home alignment changes
This change completes the Home recommendation alignment by turning response-scoped recommendation generation into a persisted workflow. Recommendation results now live on dedicated follow-up responses, planner input is source-response-aware, recommendation chips and items default to composer drafts, and follow-up asks are created early enough to survive reloads and polling recovery. Constraint: Recommendation follow-ups must remain runtime-scoped and reload-safe across thread/workbench replay Constraint: Existing Home ask/chart flows already depend on task polling and response hydration contracts Rejected: Keep recommendation data thread-scoped sidecar | owner recovery and replay stayed fragile Rejected: Persist follow-up ask only after task finishes | reload lost transient responses before hydration Confidence: high Scope-risk: moderate Directive: New recommendation and follow-up intents rely on sourceResponseId lineage — preserve it when touching composer routing or thread response creation Tested: yarn test --runInBand src/features/home/thread/useThreadCreateResponseAction.test.tsx src/features/home/thread/useThreadRecommendedQuestionsAction.test.tsx src/server/services/tests/askingService.recommendations.test.ts src/components/pages/home/promptThread/AnswerResult.test.ts src/server/services/tests/recommendationIntelligence.test.ts Tested: yarn check-types Tested: yarn lint Tested: python -m py_compile wren-ai-service/src/web/v1/services/question_recommendation.py wren-ai-service/src/web/v1/routers/question_recommendation.py wren-ai-service/src/pipelines/generation/question_recommendation.py Tested: npx playwright test e2e/specs/homeRecommendationFollowup.spec.ts --project chromium --reporter=line Not-tested: Full cross-dataset manual UX pass outside the recommendation follow-up E2E scenario
This batch removes the remaining project-scoped recommendation plumbing, keeps thread, chart-followup, and dashboard pinning on canonical workspace runtime identity, and aligns the home/workbench UI with the verified single-source thread response flow. It also carries the cleanup migrations that strip legacy recommendation fields and clear stale project bridges so fresh local verification runs on the canonical model. Constraint: Workspace-scoped runtime identity must stay consistent across thread, dashboard, and recommendation paths Constraint: The home ask/follow-up/chart flow had to stay fallback-free while local data still contained legacy project bridges Rejected: Keep legacy recommendation endpoints and fields alive behind compatibility shims | would preserve two sources of truth and prolong UI drift Rejected: Split runtime cleanup, recommendation unification, and workbench alignment into separate commits | would make the verified end-to-end flow harder to bisect Confidence: medium Scope-risk: broad Reversibility: messy Directive: Treat thread_response recommendation_detail plus workspace runtime identity as the canonical home recommendation surface; do not reintroduce project-scoped recommendation APIs Tested: yarn check-types; eslint on changed JS/TS files; yarn test --runInBand src/components/pages/home/promptThread/AnswerResult.test.ts src/components/pages/home/promptThread/ChartAnswer.test.tsx src/tests/pages/home/thread.test.tsx src/features/home/thread/threadWorkbenchMessages.test.ts src/server/backgrounds/tests/textBasedAnswerBackgroundTracker.test.ts src/server/services/tests/askingTaskTracker.test.ts src/server/services/tests/dashboardService.projectScope.test.ts src/server/services/tests/askingService.recommendations.test.ts; yarn knex migrate:status; manual Playwright ask/follow-up/chart/pin verification in sample and TiDB workspaces Not-tested: Full repository test suite and production build
This adds the retained modeling assistant alignment docs so the active Cloud-current contract is versioned instead of living only in local scratch artifacts. The docs preserve the route-first launcher, relationships review page, and semantics wizard behavior that the next implementation slices must follow. Constraint: The active Ralph execution lane uses these docs as source-of-truth inputs for the remaining modeling assistant implementation Rejected: Delete the docs with the rest of the local screenshots/debug artifacts | would leave the active task without its retained contract Rejected: Fold these docs into the previous home-thread commit | mixes two independent workstreams and weakens bisectability Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep implementation aligned to the route-first Cloud contract described here; do not regress to the earlier panel-first proposal without replacing these docs Tested: git status after restoring OMX state and local-ignore cleanup; manual doc spot-check against current retained evidence list Not-tested: Runtime or UI behavior changes (documentation-only commit)
This change brings the local modeling assistant onto the same route-first interaction shape we validated in Cloud, so the product can support relationships and semantics guidance without forcing those workflows back into the legacy setup surface. The implementation adds a modeling launcher, assistant sibling routes, route-scoped back/leave behavior, AI-service-backed relationship and semantics task endpoints, and real save/apply boundaries for both flows. The follow-up verification also tightened readonly behavior so assistant entry/save paths respect historical snapshot constraints instead of bypassing the existing modeling contract. Constraint: Must preserve the legacy /modeling compatibility redirect while adding assistant routes Constraint: No new dependencies; reuse existing modeling, runtime-scope, and polling primitives Rejected: Rebuild modeling assistant as an in-canvas panel | Cloud-current contract is route-first, not panel-first Rejected: Keep launcher hidden on embedded modeling surface | /knowledge?section=modeling is the real local entry path Confidence: medium Scope-risk: moderate Reversibility: clean Directive: Do not bypass runtime readonly/executable-snapshot guards when extending assistant routes or save endpoints Tested: yarn lint; yarn check-types; yarn test --runTestsByPath src/hooks/useRuntimeScopeNavigation.test.ts src/utils/knowledgeWorkbench.test.ts src/tests/pages/modeling-page-redirect.test.tsx src/tests/pages/modeling.test.tsx src/tests/api/relationship_recommendations_api.test.ts src/tests/api/semantics_descriptions_api.test.ts src/server/controllers/tests/projectController.saveRelationsAction.test.ts src/features/modeling/assistant/recommendRelationships/recommendRelationshipsSupport.test.ts src/features/modeling/assistant/recommendSemantics/recommendSemanticsSupport.test.ts; yarn build; npx playwright test e2e/specs/modelingAssistant.spec.ts --project=chromium --reporter=line Not-tested: Full non-mocked end-to-end AI generation against live semantics/relationship recommendation outputs
Contributor
|
Important Review skippedToo many files! This PR contains 259 files, which is 109 over the limit of 150. ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (41)
📒 Files selected for processing (259)
You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
added 4 commits
April 24, 2026 02:25
This follow-up closes the remaining gaps found during architect review by moving critical protections out of the client-only layer and by separating semantics save failures from generation failures. The assistant task APIs now enforce executable-snapshot and knowledge-base read checks before creating or reading relationship/semantics tasks, so historical or read-only scopes cannot bypass modeling protections through route-level entry points. The semantics UI also now distinguishes save failures from generation failures and offers the correct retry action. Constraint: Assistant task routes must honor the same runtime/snapshot guardrails as existing modeling reads and writes Rejected: Keep save failures inside the generic generation error banner | wrong retry path and misleading user state Confidence: high Scope-risk: narrow Reversibility: clean Directive: Any future assistant task API must enforce runtime/access guards server-side, not only through launcher visibility Tested: yarn lint; yarn check-types; yarn test --runTestsByPath src/tests/api/modelingAssistant_snapshot_access_api.test.ts src/tests/api/relationship_recommendations_api.test.ts src/tests/api/semantics_descriptions_api.test.ts src/tests/pages/modeling.test.tsx src/server/controllers/tests/projectController.saveRelationsAction.test.ts src/features/modeling/assistant/recommendRelationships/recommendRelationshipsSupport.test.ts src/features/modeling/assistant/recommendSemantics/recommendSemanticsSupport.test.ts; npx playwright test e2e/specs/modelingAssistant.spec.ts --project=chromium --reporter=line Not-tested: Full non-mocked assistant task execution against live AI outputs
This extends the Modeling AI Assistant beyond the Phase 1 contract by adding the first future-hook behaviors and by establishing a real, non-mocked AI-quality evaluation baseline for the local stack. The update adds launcher task-state reflection, activates the `openAssistant=...` deep-link handoff on modeling routes, and lets the knowledge asset wizard hand off multi-table flows directly into relationship recommendation. It also introduces a manual quality evaluation harness and a generated evaluation report across HR, ecommerce, and NBA sample datasets so Phase 2 can compare local AI output quality against Cloud observations with concrete evidence. Constraint: Future hooks must not bypass existing runtime-scope and modeling route contracts Constraint: Quality evaluation should exercise real local assistant task APIs without weakening CI stability, so the harness remains opt-in/manual Rejected: Make future hooks block parity/quality work | hooks are a separate Phase 2 lane, not the gating path for the rest of Phase 2 Rejected: Keep launcher status as a generic AI badge only | Cloud parity requires visible task-state reflection such as Todo/Done Confidence: medium Scope-risk: moderate Reversibility: clean Directive: If you expand assistant handoff further, preserve the route-first contract and keep openAssistant semantics consistent across /modeling and /knowledge?section=modeling Tested: yarn lint; yarn check-types; yarn test --runTestsByPath src/utils/knowledgeWorkbench.test.ts src/hooks/useRuntimeScopeNavigation.test.ts src/features/modeling/modelingWorkspaceUtils.test.ts src/tests/pages/modeling-page-redirect.test.tsx src/features/modeling/components/modelingAssistantStatus.test.ts; npx playwright test e2e/specs/modelingAssistant.spec.ts --project=chromium --reporter=line; RUN_MODELING_ASSISTANT_QUALITY=1 npx playwright test e2e/specs/modelingAssistantQualityEvaluation.spec.ts --project=chromium --reporter=line Not-tested: Pixel-perfect screenshot diff against Cloud pages; onboarding/asset-detail semantics handoff beyond the asset wizard multi-table path
This adds a focused regression test for the knowledge asset workbench handoff helper so future assistant/deep-link work cannot silently drop the `openAssistant` query contract when navigating from asset setup into modeling. Constraint: The handoff path must preserve the existing runtime-scoped knowledge route shape while appending assistant intent Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep assistant-intent tests close to the navigation helper so openAssistant handoff regressions surface before e2e Tested: yarn test --runTestsByPath src/features/knowledgePage/useKnowledgeAssetWorkbench.test.tsx; yarn lint src/features/knowledgePage/useKnowledgeAssetWorkbench.test.tsx --fix Not-tested: Additional cross-feature knowledge handoff permutations
This pass strengthens the Phase 2A visual layer so the assistant routes feel less like generic engineering screens and more like the structured, status-driven Cloud surfaces they are meant to mirror. The relationships and semantics pages now share richer assistant-specific visual primitives, with intro cards, status pills, clearer save/review sections, and more deliberate page rhythm. The goal is not pixel-perfect Cloud cloning yet, but a materially closer presentation of workflow state, review context, and call-to-action hierarchy. Constraint: Keep the existing Phase 1 route/save contracts unchanged while improving presentation Rejected: Rework route content into a new complex design system layer | unnecessary abstraction for a bounded parity pass Confidence: medium Scope-risk: narrow Reversibility: clean Directive: Continue Phase 2A by iterating on styling and screenshots; do not mix new orchestration behavior into visual-only passes Tested: yarn eslint src/features/modeling/components/ModelingAssistantLauncher.tsx src/features/modeling/assistant/modelingAssistantVisuals.tsx src/features/modeling/assistant/recommendRelationships/RecommendRelationshipsPage.tsx src/features/modeling/assistant/recommendSemantics/RecommendSemanticsPage.tsx --fix; yarn check-types; yarn test --runTestsByPath src/tests/pages/modeling.test.tsx src/features/modeling/components/modelingAssistantStatus.test.ts src/features/knowledgePage/useKnowledgeAssetWorkbench.test.tsx; npx playwright test e2e/specs/modelingAssistant.spec.ts --project=chromium --reporter=line Not-tested: Pixel-perfect screenshot diff against Cloud pages
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR aligns the local Modeling AI Assistant with the Cloud-current route-first interaction contract.
It adds:
/recommend-relationships/recommend-semanticsWhy
Cloud behavior is route-first, not panel-first.
The local implementation previously had no equivalent assistant route workflows, and the embedded modeling surface did not expose the launcher.
This change brings local behavior in line with the retained modeling-ai docs and validated Cloud observations.
Main changes
Verification
Passed:
cd wren-ui && yarn lintcd wren-ui && yarn check-typescd wren-ui && yarn test --runTestsByPath src/hooks/useRuntimeScopeNavigation.test.ts src/utils/knowledgeWorkbench.test.ts src/tests/pages/modeling-page-redirect.test.tsx src/tests/pages/modeling.test.tsx src/tests/api/relationship_recommendations_api.test.ts src/tests/api/semantics_descriptions_api.test.ts src/server/controllers/tests/projectController.saveRelationsAction.test.ts src/features/modeling/assistant/recommendRelationships/recommendRelationshipsSupport.test.ts src/features/modeling/assistant/recommendSemantics/recommendSemanticsSupport.test.tscd wren-ui && yarn buildcd wren-ui && npx playwright test e2e/specs/modelingAssistant.spec.ts --project=chromium --reporter=lineKnown limitations