@solidxai/core 0.1.12-beta.2 → 0.1.12-beta.4

package/docs/seed-changes.md

@@ -1,65 +0,0 @@
-# Seeding Enhancements Summary
-
-## Overview
-This document summarizes the changes made to seeding behavior in `solid-core`:
-- Metadata pruning support across targets.
-- CLI flags for selective modules and pruning.
-
-## Pruning Support
-Pruning is now available for most metadata targets. When enabled, records present in the DB but missing from JSON are removed. This is done in two phases:
-1. Identify records in DB not present in JSON.
-2. Delete those records before normal upsert seeding.
-
-### Targets with Pruning
-- Module models + fields (with model-level pruning).
-- Views, actions, menus (with join cleanup).
-- Security rules, list of values, dashboards.
-- Scheduled jobs, saved filters, model sequences.
-- Permissions (also clears role-permission join table).
-
-### Targets WITHOUT Pruning (conservative)
-- Module metadata itself
-- Media storage providers
-- Roles
-- Users
-- Email templates
-- SMS templates
-- System fields (global)
-- Default settings (global)
-
-### Pruning Mode
-Pruning runs **only** when `--prune` is provided. If omitted, pruning is skipped.
-
-## CLI Changes
-### Modules to Seed
-`--conf` was removed. Use:
-```
---modules-to-seed venue,reports
-```
-This passes `modulesToSeed` to the seeder as an array.
-
-## Sample Commands
-### Default seeding
-```
-npx @solidxai/solidctl seed
-```
-
-### Select modules only
-```
-npx @solidxai/solidctl seed --modules-to-seed venue,reports
-```
-
-### Pruning enabled
-```
-npx @solidxai/solidctl seed --modules-to-seed venue --prune
-```
-
-### Pruning enabled (all modules)
-```
-npx @solidxai/solidctl seed --prune
-```
-
-## Files Touched (Key)
-- `src/seeders/module-metadata-seeder.service.ts`
-- `src/commands/seed.command.ts`
-- `src/repository/solid-base.repository.ts` (added `findOneByUserKey`)

package/docs/test-data-workflow.md

@@ -1,200 +0,0 @@
-# Test Data Workflow
-
-This document describes the end-to-end workflow for creating isolated test databases, seeding metadata, loading test data, and tearing everything down.
-
-## Overview
-The workflow is designed to:
-- Create one **test database per configured datasource** in the project.
-- Point the app to those new databases via `.env` updates.
-- Seed all metadata into the fresh databases.
-- Load model-specific `testData` entries from module metadata JSON files.
-- Cleanly reverse everything at the end.
-
-The commands below are the canonical flow.
-
----
-
-## Step 1: Create test datasources
-
-Command:
-```
-npx @solidxai/solidctl test data --setup
-```
-
-What this does:
-- Reads all configured datasources from the Solid registry (`SolidRegistry.getSolidDatabaseModules()`), and uses their `name()` values.
-- Generates a unique **run name** (two words, underscore-separated, e.g. `steady_wolf`).
-- Builds a **timestamped database name** per datasource:
-  - `<datasource>_<timestamp>_<runName>`
-- Backs up the current `.env` into `.env.backup.<runName>`.
-- Rewrites `.env` in-place with new `*_DATABASE_NAME` values.
-- Creates the databases/schemas using TypeORM and the configured connection info.
-- Writes a `.solidx-test-manifest` with the run name + database names so the teardown can reverse everything later.
-
-Example output:
-```
-▶ Running solid test data
-Creating test datasource environment file and manifest.
-Backed up .env to .env.backup.steady_wolf and applied new test datasource names to .env.
-Creating test database/schema "default_20260201234402_steady_wolf" on datasource "default"...
-
-============================================================
-  TEST DATASOURCE ENVIRONMENT CREATED
-------------------------------------------------------------
-  Run name : steady_wolf
-  Env backup : .env.backup.steady_wolf
-
-  Test databases/schemas created:
-- default: default_20260201234402_steady_wolf
-
-  Next steps:
-  1) Using updated .env with test datasource names
-  2) Run solid seed as usual
-  3) Proceed with loading the test data for each module
-  4) Run the test cases 
-  5) Tear down
-============================================================
-
-✔ solid test data completed
-```
-
-Rationale:
-- The `.env` rewrite guarantees the app connects to fresh databases without changing code.
-- The manifest records the run so deletion is safe and deterministic.
-
----
-
-## Step 2: Seed metadata into the new databases
-
-Command:
-```
-npx @solidxai/solidctl seed
-```
-
-What this does:
-- Seeds full module metadata into the **fresh test databases**.
-- Generates the `sa` user if needed and prints its password.
-- Ensures all models, fields, roles, permissions, views, actions, etc. exist before loading test data.
-
-Example output (truncated):
-```
-▶ Running solid seed
-▶ Pruning disabled: existing metadata will be kept.
-▶ No modulesToSeed provided. Seeding ALL modules.
-▶ Seeding Metadata for Module: solid-core
-✔ [solid-core] Module/Model/Fields seeded (upserted 376)
-...
-✔ Seeding completed.
-✔ solid seed completed
-```
-
-Rationale:
-- Test data relies on model metadata and relationships; this ensures the schema and reference data are ready.
-
----
-
-## Step 3: Load test data
-
-Command:
-```
-npx @solidxai/solidctl test data --load
-```
-
-What this does:
-- Reads all module metadata files (or a subset if `--modules-to-test` is provided).
-- Looks for `testData` arrays in each metadata file.
-- Resolves the correct repository for each model (repository name pattern: `<ModelName>Repository`).
-- Performs **upsert-style** inserts using the model’s `userKeyFieldUserKey`.
-- Resolves many-to-one relations using `${fieldName}UserKey`.
-
-Example output:
-```
-▶ Running solid test data
-Test data setup for all modules.
-Processing test data for module: solid-core
-✔ Test data setup complete for module: solid-core
-Processing test data for module: venue
-✔ Test data setup complete for module: venue
-✔ solid test data completed
-```
-
-Rationale:
-- This keeps test fixtures human-readable and tied to module metadata.
-
----
-
-
-## Step 4: Run Tests 
-```
-npx @solidxai/solidctl test run --module venue --api-base-url http://localhost:3000 --ui-base-url http://localhost:5173 --headless false
-```
-
-```
-npx @solidxai/solidctl test run --module venue --list-specs
-```
-
-What this does:
-- Loads `testing.scenarios` from the module metadata file.
-- Applies `--scenario-ids` or `--include-tags` filtering if provided.
-- Boots API and UI adapters with the supplied base URLs.
-- Registers any custom test specs listed in `testing.specs`.
-- Executes scenarios in order with fail‑fast behavior.
-
-Useful variants:
-```
-npx @solidxai/solidctl test run --module venue --scenario-ids api-authenticate-success,api-create-states
-```
-
-```
-npx @solidxai/solidctl test run --module venue --include-tags smoke
-```
-
-```
-npx @solidxai/solidctl test run --module venue --api-base-url http://localhost:3000 --headless true
-```
-
-```
-npx @solidxai/solidctl test run --module venue --headless false
-```
-
-Notes:
-- If your scenario depends on a previous scenario’s `saveAs` output (e.g., `loginSuccess`), ensure the auth scenario runs first.
-- For UI tests, `--ui-base-url` should point to a running frontend server.
-- `--list-specs` prints registered custom `test.spec` ids and exits.
-
-
-## Step 5: Tear everything down
-
-Command:
-```
-npx @solidxai/solidctl test data --teardown
-```
-
-What this does:
-- Restores `.env` from the latest `.env.backup.<runName>`.
-- Deletes all `.env.backup.<runName>` files created by the workflow.
-- Drops each test database/schema recorded in `.solidx-test-manifest`.
-- Deletes the manifest file.
-
-Example output:
-```
-▶ Running solid test data
-Deleting test datasource environment and databases.
-Dropping test database/schema "default_20260201234402_steady_wolf" on datasource "default"...
-✔ Test datasource env files and manifest deleted; test databases dropped.
-✔ solid test data completed
-```
-
-Rationale:
-- Keeps the local environment clean and restores the original `.env` safely.
-
----
-
-## Optional: Limit modules for test data load
-
-You can restrict test data loading to a subset of modules:
-```
-npx @solidxai/solidctl test data --load --modules-to-test venue,reports
-```
-
-Only the listed modules are processed.

package/docs/type-declaration-import-issue.md

@@ -1,24 +0,0 @@
-# Issue: Consumer sees `Property 'id' does not exist on type 'VenueUser'`
-
-## Summary
-The published declaration files in `dist/` import internal types using `src/...` module specifiers. In a consuming project, TypeScript resolves those imports against the consumer's `src` path (or fails), which can cause `User` to extend a different `CommonEntity` that does not define `id`. This leads to `Property 'id' does not exist on type 'VenueUser'` even though `CommonEntity` in the library defines it.
-
-## Evidence
-- `dist/entities/user.entity.d.ts` starts with:
-  - `import { CommonEntity } from "src/entities/common.entity";`
-- `dist/entities/common.entity.d.ts` correctly contains:
-  - `id: number;`
-
-Because the import is `src/...`, the consumer may resolve it to their own `src` tree instead of the library's `dist` types.
-
-## Root Cause
-Library declarations are not portable because internal imports are using absolute `src/...` aliases. These aliases are not part of Node module resolution, so consumers resolve them differently.
-
-## Fix Options
-1. **Preferred:** Replace internal imports in `src/` with relative paths so emitted `.d.ts` files are portable.
-2. **Alternative:** Keep `src/*` aliases but add a post-build step (e.g., `tsc-alias`) to rewrite `dist/**/*.d.ts` imports to relative paths.
-
-## Next Steps
-- Decide on option 1 or 2.
-- Rebuild and verify `dist/**/*.d.ts` no longer import from `src/...`.
-- Publish a new package version and ensure the consuming app resolves `User` and `CommonEntity` from the same package instance.

package/docs/workflow/business-automation-example-notes.md

@@ -1,309 +0,0 @@
-# Business Automation Example Notes
-
-## Purpose
-
-This document captures a second reference workflow and the related UI observations from the accompanying screens. It builds on the earlier data-engineering example, but adds an important extra dimension: how the documentation panel should look and behave when a node is selected.
-
----
-
-## Example Workflow YAML
-
-```yaml
-id: business-automation
-namespace: tutorial
-labels:
-  name: Business Automation
-
-tasks:
-  - id: working_directory
-    type: io.kestra.plugin.core.flow.WorkingDirectory
-    description: Provide a clean working directory for downstream tasks.
-    tasks:
-      - id: query
-        type: io.kestra.plugin.jdbc.sqlite.Queries
-        description: Create and populate the SQLite features table, then return the rows.
-        url: jdbc:sqlite:kestra.db
-        fetchType: STORE
-        sql: |
-          CREATE TABLE IF NOT EXISTS features (
-            id INTEGER PRIMARY KEY,
-            name TEXT NOT NULL,
-            description TEXT NOT NULL,
-            release_version TEXT NOT NULL,
-            edition TEXT NOT NULL
-          );
-
-          DELETE FROM features;
-
-          INSERT INTO features (name, description, release_version, edition)
-          VALUES 
-              ('Worker Groups', 'Allows targeting specific tasks or triggers to run on specific remote workers for better scalability and resource management.', '0.10', 'Enterprise'),
-              ('Realtime Triggers', 'Supports triggering event-driven workflows in real-time.', '0.17', 'Open-Source'),
-              ('Task Runners', 'Provides on-demand remote execution environments for running tasks.', '0.16', 'Open-Source'),
-              ('KV Store', 'Adds key-value storage for persisting data across workflow executions.', '0.18', 'Open-Source'),
-              ('SCIM Directory Sync', 'Allows synchronization of users and groups from Identity Providers.', '0.18', 'Enterprise');  
-              
-          SELECT * FROM features
-          ORDER BY release_version;
-
-  - id: to_csv
-    type: io.kestra.plugin.serdes.csv.IonToCsv
-    description: Convert the query results to a CSV file.
-    from: "{{ outputs.query.outputs[0].uri }}"
-
-  - id: to_excel
-    type: io.kestra.plugin.serdes.excel.IonToExcel
-    description: Convert the query results to an Excel file.
-    from: "{{ outputs.query.outputs[0].uri }}"
-
-description: |
-  **Use case:** Business automation that assembles product feature data and exports it for sharing.
-  **Highlights:**
-  - Prepare a clean working directory, then build and populate a SQLite table of Kestra features.
-  - Return the ordered feature list as query results for inspection.
-  - Convert the dataset to both CSV and Excel so stakeholders can consume it in their preferred format.
-```
-
----
-
-## What This Example Adds
-
-This example is especially useful because it covers:
-
-- nested workflow structure via `WorkingDirectory`
-- a container / parent node with child tasks
-- export-oriented downstream tasks
-- a stronger documentation-panel reference
-- a topology that is more interesting than a flat linear task list
-
-The high-level shape is:
-
-```text
-Start
-  |
-  v
-working_directory
-  |
-  v
-query
-  |
-  v
-to_csv
-  |
-  v
-to_excel
-  |
-  v
-End
-```
-
-Conceptually, this also shows that the flow model needs to support grouped or scoped task containers:
-
-```text
-Workflow
-└── working_directory
-    ├── query
-    ├── to_csv
-    └── to_excel
-```
-
----
-
-## Repeated Notes From The Earlier Example
-
-The same broader detail-page guidance still applies here:
-
-- detail page is tab-oriented
-- `Topology` is read-only
-- `Executions` is a list
-- `Edit` is the primary authoring area
-- `Flow` and `Code` are the primary edit surfaces
-- `Docs` should be contextual and secondary to the main editing layout
-- `Triggers`, `Logs`, and `Metrics` remain valid long-term tabs
-- `Revisions`, `Concurrency`, and `Audit Logs` are lower priority for now
-
----
-
-## New Documentation Panel Notes
-
-This example adds much better clarity on how the documentation panel should behave.
-
-### Documentation Context
-
-The documentation shown is for the selected node type, not for the workflow as a whole.
-
-In the reference:
-
-- the selected node is `query`
-- the docs panel shows plugin documentation for `io.kestra.plugin.jdbc.sqlite.Queries`
-- the panel is contextual to the current node type
-
-So for SolidX:
-
-- docs should track the selected node type
-- when a node is selected in flow or code, the docs side panel should update accordingly
-- workflow-level documentation can exist separately, but node-type docs are the default contextual behavior in the editor
-
----
-
-## Documentation Panel Structure
-
-The documentation panel in this example has a very clear internal structure:
-
-- breadcrumb / hierarchy
-- title
-- optional badge / release-notes affordance
-- prose description
-- typed code identity block
-- collapsible documentation sections
-
-### Observed Sections
-
-- `Examples`
-- `Properties`
-- `Outputs`
-- `Metrics`
-- `Definitions`
-
-This aligns strongly with the node metadata contract we have already started shaping.
-
----
-
-## Documentation Content Expectations
-
-This example suggests each node type should be able to expose enough metadata to render:
-
-### Examples
-
-- one or more example snippets
-- copy-friendly blocks
-- short narrative explaining the example
-
-### Properties
-
-- field names
-- required vs optional indication
-- type badges
-- support for union-ish displays like `Integer | String`
-- support for object / array / boolean / string / numeric property shapes
-
-### Outputs
-
-- named outputs
-- output type
-- compact typed list presentation
-
-### Metrics
-
-- available metrics exposed by the node type
-- metric name
-- metric kind such as `Counter`
-
-### Definitions
-
-- deeper technical definitions or linked schema-level structures
-- collapsible advanced sections
-
----
-
-## Implications For SolidX Node Metadata
-
-This example reinforces that the node-definition contract should be rich enough to drive docs directly from backend metadata.
-
-The docs panel should be primarily schema- and metadata-driven, not hardcoded per node.
-
-The ideal default path remains:
-
-- backend node metadata defines docs content
-- frontend renders docs generically
-
-Escape hatches remain useful for special nodes, but they should not be the main path.
-
----
-
-## Topology Notes From This Example
-
-This example also adds an important topology detail:
-
-- grouped or scoped containers should be visually represented
-- the `working_directory` task appears as a visual parent/container around its child tasks
-
-For SolidX, this implies future flow rendering should support:
-
-- nested node groups
-- container boundaries
-- child-task layout inside a parent control/container node
-
-This does not need to be fully solved in the very first pass, but it should be considered part of the intended contract.
-
----
-
-## Editor Layout Notes Confirmed Again
-
-The screenshot again supports the desired edit composition:
-
-- left: workflow code
-- center/right: topology / flow canvas
-- right-side docs panel: contextual node documentation
-
-This means the editor should feel like a multi-surface workstation rather than a single form page.
-
----
-
-## Metrics Note
-
-This example visually shows `Metrics` inside the docs panel for a node type.
-
-That is different from workflow runtime metrics reporting.
-
-So there are really two meanings of metrics in the UX:
-
-### Node Documentation Metrics
-
-- what metrics a node can emit
-- static metadata
-- safe to document now
-
-### Workflow Runtime Metrics
-
-- actual measured emitted metric data from executions
-- requires persistence / backing tables / querying
-- later feature
-
-This distinction is important and should be preserved in our documentation and implementation.
-
----
-
-## Pending Feature Notes
-
-This example highlights a few still-pending capabilities:
-
-- generic documentation side panel driven from node metadata
-- nested/grouped flow rendering for container nodes
-- runtime metrics persistence and reporting
-- richer definitions rendering
-- example snippet copy UX
-
----
-
-## Screenshot References
-
-These screenshots informed the notes above:
-
-- `/Users/harishpatel/Desktop/Screenshot 2026-07-10 at 17.09.09.png`
-- `/Users/harishpatel/Desktop/Screenshot 2026-07-10 at 17.09.25.png`
-- `/Users/harishpatel/Desktop/Screenshot 2026-07-10 at 17.09.33.png`
-- `/Users/harishpatel/Desktop/Screenshot 2026-07-10 at 17.09.40.png`
-- `/Users/harishpatel/Desktop/Screenshot 2026-07-10 at 17.09.47.png`
-
----
-
-## Recommended Follow-On Use
-
-This example should be used as a reference for:
-
-1. contextual node documentation rendering
-2. generic docs-section UI design
-3. grouped / container node visualization
-4. nested workflow-structure handling in the flow canvas
-5. clarifying the difference between documented metrics and persisted runtime metrics