loadFromDirectory() was missing the tenantId field auto-add logic that
loadFromFile() already had, causing "Unknown field: tenantId" on all
entities using the shorthand `"tenantId": true` convention.
Also corrected ComponentNode schema to match the C++ struct fields
(pageId, parentId, childIds, order) instead of the wrong Redux shape.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Without seed data the Settings endpoint returns 404, causing the
frontend to fall back to hardcoded defaults on every page load.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The DBAL sync client referenced these 4 entities but no JSON schema files
existed, causing 422 Unprocessable Entity on CodeForge page load.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Remove stale dirs/files superseded by metabuilder-small's reorganization:
- Old YAML entity/seed files (migrated to JSON)
- Root-level workflowui/ (moved to frontends/workflowui/)
- Prisma, Pyodide, old hooks, bun.lock artifacts
- Legacy scratch docs (txt/, docs/, deployment/*.md)
- Stale CI workflows consolidated in small
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Updated gen_prisma_schema.js to parse YAML entity schemas
- Generated Prisma models for EmailClient, EmailFolder, EmailMessage, EmailAttachment
- All email models include proper indexes and constraints from YAML definitions
- Schema generation now supports dynamic YAML parsing with fallback to core models
Add core seed data:
- /dbal/shared/seeds/database/users.yaml - Default system users (supergod, admin, testuser)
- /dbal/shared/seeds/database/credentials.yaml - SHA-512 hashed passwords
Add dashboard components:
- dashboard_home - User greeting with quick navigation links
- user_profile - User profile information display
- comments_list - Paginated comments list
- comment_form - Comment submission form
- irc_chat - IRC-style chat interface
These components use fakemui Material Design components and follow the
MetaBuilder JSON component schema. They provide the foundation for the
dashboard package migration from the old system.
Add README to /dbal/shared/seeds/database explaining:
- Philosophy: Root seed = minimal, Packages = everything
- Structure: Only installed_packages.yaml and package_permissions.yaml
- Data flow: How bootstrap loads package entity folders
- What NOT to put here (all entity-specific data goes in packages)
- Idempotency guarantees
- How to add new core packages
This establishes the architecture:
1. DBAL seed contains only:
- List of 12 core packages to install
- System permissions and roles
2. Everything else goes in packages:
- PageConfig (pages/routes)
- Workflows
- Credentials
- Notifications
- Components
- Package-specific seed data
This clean separation means:
- Root DBAL is minimal and stable
- Packages are self-contained
- Easy to add/remove packages
- Clear organization
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- Fix seedDatabase() to use Prisma directly, bypassing ACL validation for system packages
- Update path resolution in seedDatabase() to work from dist directory
- Create load-and-apply.ts seed orchestration entry point
- Fix environment variable loading in createDBALClient factory
- Update PrismaAdapter to check process.env.DATABASE_URL as fallback
- Update createPrismaContext to use env DATABASE_URL with absolute fallback path
- Add dotenv import to seed script to ensure environment variables are loaded
- Fix relative path issues that prevented database connection in seed script
- Database now successfully seeded with 12 packages and homepage route
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
CHANGES:
- Removed datasource url from schema (Prisma 7 incompatibility)
- Schema lives at /dbal/shared/prisma/schema.prisma
- Database URL will be provided via environment variable at runtime
- Created .env.local for development (file:./prisma/dev.db)
- Prisma client will create/initialize database on first connection
NOTE: Prisma 7 CLI doesn't support db:push without URL in schema OR config.
The solution is to let the PrismaClient adapter create the database on first connection.
For local development: DATABASE_URL="file:./dbal/development/prisma/dev.db"
For tests: DATABASE_URL="file::memory:" or environment-specific config
Database will be automatically initialized when:
1. getDBALClient() is called with environment config
2. PrismaClient adapter connects to the URL
3. Tables are created from schema on first access
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
The Prisma schema is the single source of truth for the entire system
and should live in shared, not in development-specific location.
MOVED:
- /dbal/development/prisma/schema.prisma → /dbal/shared/prisma/schema.prisma
UPDATED:
- DBAL package.json: db:* scripts reference ../shared/prisma/schema.prisma
- config package.json: schema reference updated
- gen_prisma_schema.js: outputs to shared location
STRUCTURE NOW:
- /dbal/shared/prisma/ - Prisma schema (source of truth)
- /dbal/shared/seeds/ - Seed data (YAML files)
- /dbal/development/ - Uses shared schema via relative path
This ensures:
✅ Single source of truth for schema
✅ Schema is shared across all implementations (Phase 2 TypeScript, Phase 3 C++)
✅ Development just references the shared schema
✅ Independent deployability maintained
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
MOVED:
- /seed/ → /dbal/shared/seeds/
- database/ (installed_packages.yaml, package_permissions.yaml)
- config/ (bootstrap.yaml, package-repo.yaml)
- packages/ (core-packages.yaml)
- /prisma/schema.prisma → /dbal/development/prisma/schema.prisma
UPDATED:
- Root package.json: db:* scripts delegate to dbal/development
- Frontend package.json: db:* scripts delegate to dbal/development
- DBAL package.json: Added db:migrate and db:seed scripts
- /dbal/development/src/seeds/index.ts: Updated paths to new seed location
- /dbal/shared/tools/codegen/gen_prisma_schema.js: Output to new schema location
- /config/package.json: Updated schema path references
DELETED:
- /seed/ folder (moved to DBAL)
- /prisma/ folder (moved to DBAL)
BENEFITS:
- DBAL is now self-contained and independently deployable
- Single source of truth for seeds and schema
- Clear separation: database logic in DBAL, frontend in /frontends/
- All db:* commands now go through DBAL, not duplicated in frontend
This restructure is MANDATORY FIRST STEP before CODEBASE_RECOVERY_PLAN execution.
Architecture must be fixed before code cleanup happens.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- Added `jsonScript` property to metadata schema for JSON script entry points.
- Refactored `generate-package.ts` to replace Lua scripts with JSON scripts for lifecycle hooks.
- Updated test generation to use JSON format for metadata validation.
- Modified documentation and comments to reflect the transition from Lua to JSON scripting.
- Adjusted Storybook configuration and mock data to align with new JSON script structure.
- Renamed relevant files and references from Lua to JSON for consistency across the project.
- Deleted all LuaScript CRUD operations from Client and entities.
- Removed LuaScript validation functions and related files.
- Updated InMemoryStore to remove LuaScript storage.
- Cleaned up tests by removing LuaScript related test cases.
- Adjusted documentation and quick start guide to reflect the removal of LuaScript functionality.
- Updated `list_workflows.hpp` to replace `is_active` with `enabled` filter and added `tenant_id` filter.
- Modified sorting logic for workflows based on `created_at` to handle optional values.
- Enhanced `update_workflow.hpp` to include new fields: `nodes`, `edges`, `enabled`, `version`, and `created_at`.
- Removed obsolete `isValidWorkflowTrigger` validation function from `workflow_validation.hpp`.
- Adjusted unit tests in `client_test.cpp` to reflect changes in workflow and page management, including renaming fields and updating assertions.
- Updated Prisma schema in `schema.prisma` to align with new workflow and component models, including changes to data types and attributes.
- Introduced a new script `gen_prisma_schema.js` for generating Prisma schema from DBAL API schemas to maintain synchronization.
- Introduced `PageConfig` entity for page configuration and layout definition.
- Introduced `ComponentNode` entity for managing component hierarchy within pages.
- Implemented operations for creating, reading, updating, and deleting both entities.
- Updated Prisma schema to reflect new entities and relationships.
- Enhanced ACL rules for new entities to manage access control.
- Added conformance cases to test page and component hierarchy management.
- Created a script to check synchronization between DBAL and Prisma schemas.
- Created dbal/shared/ui directory for shared UI components
- Implemented getStatusResponse() for status API endpoint
- Implemented DBALDaemonPage component with metadata
- Updated tsconfig.json @dbal-ui path to point to dbal/shared/ui
- Updated next.config.ts webpack alias for @dbal-ui
- Components support both development and production DBAL modes
Co-authored-by: johndoe6345789 <224850594+johndoe6345789@users.noreply.github.com>