odac 0.9.0 → 1.0.0

package/test/server/__mocks__/fs.js

@@ -12,10 +12,10 @@ const resetFileSystem = () => {
   mockDirectories.clear()
 
   // Add some default directories
-  mockDirectories.add('/var/candypack')
+  mockDirectories.add('/var/odac')
   mockDirectories.add('/etc/ssl/private')
   mockDirectories.add('/etc/ssl/certs')
-  mockDirectories.add('/home/user/.candypack')
+  mockDirectories.add('/home/user/.odac')
 }
 
 // Initialize with default state

package/test/server/__mocks__/{globalCandy.js → globalOdac.js}

@@ -1,9 +1,9 @@
 /**
- * Comprehensive mock for the global Candy object used in server tests
+ * Comprehensive mock for the global Odac object used in server tests
  * Provides mocked implementations of core(), server(), cli(), and watchdog() methods
  */
 
-class MockCandyPack {
+class MockOdac {
   constructor() {
     this._registry = new Map()
     this._singletons = new Map()
@@ -215,13 +215,13 @@ class MockCandyPack {
 }
 
 // Create the global mock instance
-const mockCandy = new MockCandyPack()
+const mockOdac = new MockOdac()
 
 // Mock the global __ function
 const mockLangGet = jest.fn(key => key)
 
 module.exports = {
-  mockCandy,
+  mockOdac,
   mockLangGet,
-  MockCandyPack
+  MockOdac
 }

package/test/server/__mocks__/index.js

@@ -14,7 +14,7 @@ const os = require('./os')
 const path = require('./path')
 
 // Import test utilities
-const {mockCandy, mockLangGet, MockCandyPack} = require('./globalCandy')
+const {mockCandy, mockLangGet, MockOdac} = require('./globalCandy')
 const testFactories = require('./testFactories')
 const testHelpers = require('./testHelpers')
 
@@ -34,11 +34,11 @@ const setupNodeMocks = () => {
 }
 
 /**
- * Setup global mocks (Candy and __ function)
+ * Setup global mocks (Odac and __ function)
  * Call this in beforeEach to set up global mocks
  */
 const setupGlobalMocks = () => {
-  global.Candy = mockCandy
+  global.Odac = mockCandy
   global.__ = mockLangGet
 
   // Clear all previous mock calls
@@ -66,7 +66,7 @@ const cleanupAllMocks = () => {
   path.__resetMocks()
 
   // Reset global references
-  delete global.Candy
+  delete global.Odac
   delete global.__
 }
 
@@ -93,7 +93,7 @@ const createTestEnvironment = () => {
 
     // Global mocks
     global: {
-      Candy: mockCandy,
+      Odac: mockCandy,
       __: mockLangGet
     },
 
@@ -233,7 +233,7 @@ module.exports = {
   // Global mocks
   mockCandy,
   mockLangGet,
-  MockCandyPack,
+  MockOdac,
 
   // Test utilities
   testFactories,

package/test/server/__mocks__/testFactories.js

@@ -9,7 +9,7 @@
 const createMockWebsiteConfig = (domain = 'example.com', overrides = {}) => {
   return {
     domain,
-    path: `/var/candypack/${domain}`,
+    path: `/var/odac/${domain}`,
     subdomain: ['www'],
     cert: {
       ssl: {

package/test/server/__mocks__/testHelpers.js

@@ -3,21 +3,21 @@
  * Provides helper functions to reduce boilerplate in server tests
  */
 
-const {mockCandy, mockLangGet} = require('./globalCandy')
+const {mockOdac, mockLangGet} = require('./globalOdac')
 
 /**
- * Sets up the global Candy mock and __ function for tests
+ * Sets up the global Odac mock and __ function for tests
  * Should be called in beforeEach or beforeAll
  */
 const setupGlobalMocks = () => {
-  // Set up global Candy mock
-  global.Candy = mockCandy
+  // Set up global Odac mock
+  global.Odac = mockOdac
 
   // Set up global __ function mock
   global.__ = mockLangGet
 
   // Clear all previous mock calls
-  mockCandy.clearMocks()
+  mockOdac.clearMocks()
   mockLangGet.mockClear()
 }
 
@@ -26,11 +26,11 @@ const setupGlobalMocks = () => {
  * Should be called in afterEach or afterAll
  */
 const cleanupGlobalMocks = () => {
-  mockCandy.resetMocks()
+  mockOdac.resetMocks()
   mockLangGet.mockClear()
 
   // Reset global references
-  delete global.Candy
+  delete global.Odac
   delete global.__
 }
 

package/.husky/pre-commit

@@ -1,2 +0,0 @@
-npx lint-staged
-node test/scripts/check-coverage.js

package/.kiro/steering/code-style.md

@@ -1,56 +0,0 @@
----
-inclusion: always
----
-
-# Code Style Guidelines
-
-## Comments
-
-- **Language**: All code comments MUST be written in English
-- **Minimalism**: Avoid unnecessary comments - write self-documenting code instead
-- **When to comment**: Only add comments when the code's intent is not immediately clear from the code itself
-- **What not to comment**: 
-  - Obvious operations (e.g., `// Set variable` before `x = 5`)
-  - Code that explains itself through clear naming
-  - Redundant descriptions of what the code does
-
-## Examples
-
-### Bad (unnecessary comments):
-```javascript
-// Get user email
-const email = user.email
-
-// Loop through items
-for (const item of items) {
-  // Process item
-  processItem(item)
-}
-```
-
-### Good (self-documenting):
-```javascript
-const email = user.email
-
-for (const item of items) {
-  processItem(item)
-}
-```
-
-### Good (necessary comment):
-```javascript
-// ACME protocol requires 30-second delay between retries
-await sleep(30000)
-
-// Workaround for MySQL connection pool bug in v2.3.0
-if (connection.threadId === null) {
-  connection = await reconnect()
-}
-```
-
-## General Principles
-
-- Let the code speak for itself through clear variable and function names
-- Use comments sparingly to explain "why" not "what"
-- Keep comments concise and to the point
-- Update or remove comments when code changes

package/.kiro/steering/product.md

@@ -1,20 +0,0 @@
-# CandyPack Product Overview
-
-CandyPack is a next-generation server and framework toolkit that combines hosting infrastructure with a web development framework. It's designed as a lightweight, zero-config solution for building and deploying modern web applications.
-
-## Core Components
-
-- **Server**: Full-featured hosting platform with DNS, SSL, mail server (IMAP/SMTP), and multi-domain support
-- **Backend**: Web application framework with routing, authentication, CSRF protection, and internationalization
-- **Frontend**: Client-side framework (candy.js) with AJAX navigation, form handling, and API requests
-- **CLI**: Command-line interface for server management and deployment
-- **Watchdog**: Process monitoring and management system
-
-## Key Philosophy
-
-- **Developer-first**: Zero-config approach, focus on code rather than infrastructure
-- **Performance-oriented**: Lightweight and optimized for speed
-- **Security-focused**: Built-in CSRF protection, SSL automation, secure defaults
-- **Global-ready**: Multi-language support and internationalization built-in
-
-The project follows AGPL-3.0 licensing and targets Node.js 18+ environments.

package/.kiro/steering/structure.md

@@ -1,77 +0,0 @@
-# Project Structure & Architecture
-
-## Directory Organization
-
-```
-├── bin/              # Executable binaries (candy, candypack)
-├── cli/              # Command-line interface
-│   └── src/          # CLI implementation (Cli.js, Connector.js, Monitor.js)
-├── core/             # Core dependency injection system
-├── framework/        # Web framework implementation
-│   ├── src/          # Framework modules (Auth, Route, Server, etc.)
-│   └── web/          # Client-side JavaScript (candy.js)
-├── server/           # Server infrastructure
-│   └── src/          # Server modules (DNS, SSL, Mail, Web, etc.)
-├── watchdog/         # Process monitoring system
-├── web/              # Template website (copied when creating new sites)
-│   ├── controller/   # Template controllers
-│   ├── package.json  # Template package.json with {{domain}} placeholders
-│   └── config.json   # Template configuration
-├── docs/             # Documentation (backend, frontend & server)
-│   ├── index.json    # Documentation navigation structure
-│   ├── backend/      # Backend documentation files
-│   ├── frontend/     # Frontend documentation files
-│   └── server/       # Server documentation files
-├── locale/           # Internationalization files
-└── test/             # Jest test files
-```
-
-## Architecture Patterns
-
-### Dependency Injection (Core)
-
-- **Global Candy**: Singleton registry pattern via `global.Candy`
-- **Module Loading**: Dynamic require with `core()`, `cli()`, `server()`, `watchdog()` methods
-- **Singleton Management**: Automatic instantiation and caching
-
-### Framework Pattern
-
-- **Request Lifecycle**: Each request gets a fresh Candy instance with req/res context
-- **Controller Pattern**: Simple function exports in `controller/` directories
-- **Helper Functions**: Global shortcuts (`__()`, `abort()`, `return()`, etc.)
-
-### File Naming Conventions
-
-- **PascalCase**: Class files and main modules (e.g., `Candy.js`, `Server.js`)
-- **camelCase**: Utility functions and instances
-- **lowercase**: Entry points (`index.js`)
-
-### Module Structure
-
-- Each module can have an optional `init()` method for setup
-- Framework modules receive Candy instance for request context
-- Server modules are typically singletons for infrastructure
-
-### Web Template System
-
-- **Template Directory**: `web/` serves as the template for new websites
-- **Automatic Copying**: When creating a new site, entire `web/` directory is copied
-- **Template Variables**: Files can contain placeholders like `{{domain}}` and `{{domain_original}}`
-- **Post-Processing**: After copying, template variables are replaced with actual values
-- **Template Files**:
-  - `package.json` - Contains domain placeholders for name and description
-  - `config.json` - Basic routing configuration
-  - `controller/` - Example controller implementations
-
-### Documentation System
-
-- **Index File**: `docs/index.json` contains the navigation structure for all documentation
-- **Adding New Docs**: When creating new documentation files, they MUST be added to `docs/index.json`
-- **Language**: All documentation content must be written in English
-- **Structure**: Documentation is organized into THREE sections only:
-  - `docs/server/` - Server infrastructure documentation (CLI, DNS, SSL, Mail)
-  - `docs/backend/` - Backend framework documentation (Controllers, Routing, Auth, Database)
-  - `docs/frontend/` - Frontend documentation (candy.js, AJAX navigation, Forms)
-- **IMPORTANT**: There is NO `docs/framework/` directory - backend docs go in `docs/backend/`
-- **File Organization**: Each section has folders with numbered prefixes (01-overview, 02-structure, etc.)
-- **Navigation**: The index.json file defines the title and hierarchy shown in documentation site

package/.kiro/steering/tech.md

@@ -1,87 +0,0 @@
-# Technology Stack & Build System
-
-## Tech Stack
-
-- **Runtime**: Node.js 18+ (required)
-- **Language**: JavaScript (ES6+, CommonJS modules)
-- **Database**: MySQL2, SQLite3 support
-- **Security**: bcrypt, node-forge, ACME client for SSL
-- **Mail**: Built-in SMTP/IMAP server with DKIM signing
-- **Proxy**: HTTP proxy for multi-domain hosting
-- **DNS**: Native DNS server implementation
-
-## Code Quality Tools
-
-- **Linting**: ESLint with Prettier integration
-- **Testing**: Jest with coverage reporting (no threshold enforcement)
-- **Git Hooks**: Husky with pre-commit linting and test execution
-- **Release**: Semantic Release with conventional commits
-- **Test Check**: Automatic test execution on commit for changed files (pass/fail only)
-
-## Common Commands
-
-```bash
-# Development
-npm run lint          # Run ESLint
-npm run lint:fix      # Fix linting issues automatically
-npm test              # Run Jest tests with coverage
-npm run test:watch    # Run tests in watch mode
-
-# Release
-npm run release       # Semantic release (automated)
-
-# Installation
-curl -sL https://candypack.dev/install | bash  # Quick install
-npm install -g candypack                       # Manual install
-
-# Git Hooks & CI/CD
-# Pre-commit automatically runs:
-# 1. lint-staged (ESLint + Prettier on staged files)
-# 2. Test execution for changed core/ and server/ files (test/scripts/check-coverage.js)
-# Note: Coverage is tracked but doesn't block commits - focus is on test pass/fail
-
-# GitHub Actions (on PR to main/dev):
-# 1. Runs all tests with coverage
-# 2. Runs linter
-# 3. Tests on Node.js 18.x and 22.x
-# 4. Uploads coverage to Codecov
-# 5. Comments PR with coverage report
-```
-
-## Code Style
-
-- **Prettier Config**: No semicolons, single quotes, 140 char width, 2-space tabs
-- **ESLint**: Separate configs for server/framework/web/browser contexts
-- **Globals**: `Candy` and `__` are global variables across the codebase
-- **Module System**: CommonJS (`require`/`module.exports`) for server-side code
-
-## Logging Standards
-
-### Server & Core Modules
-- **Log Class**: Use `Candy.core('Log', false).init('ModuleName')` for all logging in `server/` and `core/` directories
-- **Usage Pattern**:
-
-  ```javascript
-  const {log, error} = Candy.core('Log', false).init('ModuleName')
-
-  log('Info message')
-  log('Message with %s placeholder', 'value')
-  error('Error message', errorObject)
-  ```
-
-- **CLI Mode**: Logs are automatically suppressed in CLI mode to avoid breaking the interface
-- **Location**: Log class is in `core/Log.js` (also available via `server/src/Log.js` for backward compatibility)
-
-### Framework Modules
-- **Console Logging**: Use `console.log()` and `console.error()` directly in `framework/` directory
-- **Reason**: Framework runs in user's application context where Log class may not be available
-- **Usage Pattern**:
-
-  ```javascript
-  console.log('[ModuleName] Info message')
-  console.error('[ModuleName] Error:', error.message)
-  ```
-
-### General Rule
-- **Server/Core**: Always use Log class (never `console.log`)
-- **Framework**: Always use `console.log` (Log class not guaranteed to be available)

package/AGENTS.md

@@ -1,84 +0,0 @@
-# AGENTS Guidelines for This Repository
-
-This document provides a comprehensive guide for developers working on the CandyPack source code. It covers the project's architecture, class system, directory structure, and usage patterns.
-
-## 1. Project Overview
-
-CandyPack is a toolkit for building and deploying web applications, consisting of two main parts:
-1.  **A Core System**: A background service that manages servers (web, mail, etc.), process monitoring, and provides a command-line interface (CLI).
-2.  **A Web Framework**: A lightweight framework for building the actual web applications that are served by the core system.
-
-## 2. Core Architecture (`core/Candy.js`)
-
-The heart of the core system is a service container implemented in `core/Candy.js`. This module creates a global singleton object named `Candy`.
-
-### Service Container
-
-The `Candy` object acts as a service locator and dependency injection container. It can dynamically load and cache modules (services) from different parts of the application.
-
--   **Registration and Resolution**: Modules are registered with a key and can be resolved (retrieved) using that key. The container handles the instantiation of classes and can cache them as singletons.
--   **Module Loaders**: It has dedicated methods for loading modules from specific directories:
-    -   `Candy.core(name)`: Loads a module from the `core/` directory.
-    -   `Candy.cli(name)`: Loads a module from the `cli/src/` directory.
-    -   `Candy.server(name)`: Loads a module from the `server/src/` directory.
-    -   `Candy.watchdog(name)`: Loads a module from the `watchdog/src` directory.
-
-**Example Usage:**
-To access the application's configuration manager (defined in `core/Config.js`), you would use:
-```javascript
-const config = Candy.core('Config');
-```
-
-## 3. Web Framework Architecture (`framework/src/Candy.js`)
-
-The web framework provides the tools to build a website or API. Its main entry point is `framework/src/Candy.js`. Unlike the core `Candy` object, the framework creates a **request-specific instance** for every incoming HTTP request.
-
-### Request-Specific Context
-
-When a web request hits the server, the framework's `instance()` method is called to create a `_candy` object. This object is a "context" that holds all the necessary components for handling that specific request.
-
-This context object includes:
--   `Request`: An object representing the incoming HTTP request.
--   `View`: A view renderer for HTML pages.
--   `Auth`: An authentication manager.
--   `Token`: A CSRF token handler.
--   `Lang`: An internationalization (i18n) helper.
--   `Mysql`: A database connection handler.
-
-It also attaches numerous helper functions to the context object for convenience within a controller, such as:
--   `return(data)`: Ends the request and sends data back to the client.
--   `direct(url)`: Redirects the client to a new URL.
--   `cookie(key, value)`: Sets a cookie.
--   `validator()`: Creates a new input validator.
-
-This context object is passed to the controller function that handles the route.
-
-## 4. Directory Structure Guide
-
--   `bin/`: Executable scripts for the CLI (`candy`, `candypack`).
--   `cli/`: Source code for the CLI. The main logic is in `cli/src/Cli.js`.
--   `core/`: Core application logic and shared modules (e.g., `Config.js`, `Commands.js`).
--   `framework/`: The source code for the web framework.
--   `server/`: Low-level server implementations (HTTP, Mail, DNS, SSL).
--   `web/`: **This is a template for a user's website.** When a new site is created with CandyPack, this directory is copied to serve as the starting point.
-    -   `web/index.js`: The entry point for a web application. It initializes the framework.
-    -   `web/route/`: Contains route definition files.
-    -   `web/controller/`: Contains controller files.
-    -   `web/view/`: (Assumed) Would contain HTML templates for the `View` engine.
-    -   `web/config.json`: Application-specific configuration.
--   `test/`: Project test files.
--   `watchdog/`: A process monitor that ensures the main CandyPack server stays running.
-
-## 5. Using the CLI (`bin/candy`)
-
-The `candy` command is the main tool for managing the CandyPack server.
-
--   `candy`: Shows the server status (online/offline, uptime, etc.) and lists available commands.
--   `candy start`: (Inferred) Starts the CandyPack server daemon.
--   `candy stop`: (Inferred) Stops the server.
--   `candy restart`: (Inferred) Restarts the server.
--   `candy monitor`: Opens an interactive terminal UI to monitor the status of all hosted websites and services.
--   `candy debug`: Opens an interactive UI to view live logs from different core modules.
--   `candy help <command>`: Shows detailed help for a specific command.
-
-The commands are defined in `core/Commands.js` and implemented in various modules, primarily `cli/src/Cli.js`.

package/bin/candy

@@ -1,10 +0,0 @@
-#!/usr/bin/env node
-
-let args = process.argv
-if(process.argv[0].includes('node')) args = process.argv.slice(1)
-if (args[1] === 'framework') {
-  require('../framework/index.js')
-  return
-}
-
-require('../cli/index.js')

package/bin/candypack

@@ -1,10 +0,0 @@
-#!/usr/bin/env node
-
-let args = process.argv
-if(process.argv[0].includes('node')) args = process.argv.slice(1)
-if (args[1] === 'framework') {
-  require('../framework/index.js')
-  return
-}
-
-require(args.includes('watchdog') ? '../watchdog/index.js' : '../cli/index.js')

package/cli/index.js

@@ -1,3 +0,0 @@
-require('../core/Candy.js')
-
-Candy.cli('Cli')