PHPackages citomni/app-skeleton - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Framework](/categories/framework) 4. / 5. citomni/app-skeleton ActiveProject[Framework](/categories/framework) citomni/app-skeleton ==================== Neutral application skeleton for CitOmni. Provides the app container, core wiring points, and installer lifecycle tooling without assuming HTTP or CLI mode. v1.0.0.1(1mo ago)011MITPHP ^8.2 Since Jun 3Pushed 1mo agoCompare [ Source](https://github.com/citomni/app-skeleton)[ Packagist](https://packagist.org/packages/citomni/app-skeleton)[ Docs](https://www.citomni.com)[ GitHub Sponsors](https://github.com/LarsGMortensen)[ Fund](https://ko-fi.com/)[ RSS](/packages/citomni-app-skeleton/feed)WikiDiscussions main Synced 1w ago READMEChangelog (1)Dependencies (4)Versions (3)Used By (0) CitOmni App Skeleton ==================== [](#citomni-app-skeleton) Neutral application skeleton for CitOmni. `citomni/app-skeleton` is the mode-neutral starting point for CitOmni applications. It provides the application container, app-owned root files, neutral source-layer folders, common config entry points, runtime state folders, defensive `.htaccess` files, and installer lifecycle tooling. It does **not** assume that the application is an HTTP app, a CLI app, or both. HTTP and CLI support are added explicitly through `citomni/http` and `citomni/cli`. Lean, deterministic, and pleasantly boring where boring is a feature. --- Highlights ---------- [](#highlights) - **Mode-neutral application container** for CitOmni projects. - **No HTTP assumption** by default: No `public/`, no `templates/`, no HTTP routes, and no web front controller until `citomni/http` is installed. - **No CLI assumption** by default: No `bin/citomni` launcher until `citomni/cli` is installed. - **Installer-ready lifecycle model** through `citomni/installer`. - **App-owned common config entry points** for shared cfg, providers, and local services. - **Canonical source-layer folders** for operations, repositories, services, policies, state handlers, support classes, enums, utilities, and exceptions. - **Shared-hosting defense-in-depth** through deny rules in internal folders. - **Deterministic line endings** through `.gitattributes`. --- What this package is -------------------- [](#what-this-package-is) `citomni/app-skeleton` is the neutral application root for CitOmni. It exists so new applications can start from a clean, mode-free structure and then explicitly opt into the runtime modes they need. A new application may become: - An HTTP application. - A CLI application. - A combined HTTP and CLI application. - A base for a richer DevKit-driven workflow. The skeleton itself stays small. Runtime-near scaffold files are owned by the package that needs them. Examples: - `public/index.php` is owned by `citomni/http`. - `templates/` is owned by `citomni/http`. - `bin/citomni` is owned by `citomni/cli`. - Scaffold materialization is handled by `citomni/installer`. This keeps ownership visible and avoids turning the starter project into a drawer full of maybe-useful files. --- What this package provides -------------------------- [](#what-this-package-provides) `citomni/app-skeleton` provides the app-owned baseline structure. That includes: - Root Composer project metadata. - PSR-4 application autoloading. - App-owned common configuration files. - Shared cfg, provider, and service entry points. - Neutral source-layer directories. - Language directories. - Runtime state directories under `var/`. - Defensive `.htaccess` files for internal folders. - `.gitattributes` for deterministic line endings. - `citomni/installer` as lifecycle tooling. It gives the application a safe place to exist before any runtime mode is installed. --- What this package does not provide ---------------------------------- [](#what-this-package-does-not-provide) `citomni/app-skeleton` deliberately does **not** provide: - HTTP runtime behavior. - CLI runtime behavior. - HTTP front controller files. - CLI launcher files. - HTTP routes. - CLI commands. - HTML templates. - Public webroot files. - Deployment profiles. - Application business logic. Those belong to runtime packages, provider packages, DevKit, or the application itself. No ceremonial `public/` directory for pure CLI apps. No `bin/citomni` launcher for pure HTTP apps. The filesystem should not cosplay as a framework decision. --- Requirements ------------ [](#requirements) - PHP **8.2+** - Composer - `citomni/kernel` - `citomni/installer` OPcache is strongly recommended in production once a runtime mode has been installed. --- Installation ------------ [](#installation) Create a new neutral CitOmni application: ``` composer create-project citomni/app-skeleton my-app cd my-app ``` At this point the application is intentionally neutral. It has no HTTP or CLI runtime mode yet. --- Add HTTP support ---------------- [](#add-http-support) Install the HTTP runtime package: ``` composer require citomni/http composer citomni:install:http ``` Direct equivalent, if you do not use Composer scripts: ``` vendor/bin/citomni-installer install --package=citomni/http ``` This materializes HTTP-owned scaffold such as: ``` public/index.php public/.htaccess public/assets/.gitkeep public/uploads/.htaccess config/citomni_http_cfg.php config/citomni_http_cfg.dev.php config/citomni_http_cfg.stage.php config/citomni_http_cfg.prod.php config/citomni_http_routes.php config/citomni_http_routes.dev.php config/citomni_http_routes.stage.php config/citomni_http_routes.prod.php config/services_http.php src/Http/Controller/AppController.php templates/.htaccess templates/public/.gitkeep templates/member/.gitkeep templates/admin/.gitkeep ``` After this, point your web server document root to: ``` public/ ``` For local development, you can use PHP's built-in server: ``` php -S 127.0.0.1:8000 -t public ``` For the full scaffold lifecycle manual, see the [CitOmni Installer README](https://github.com/citomni/installer/blob/main/README.md). --- Add CLI support --------------- [](#add-cli-support) Install the CLI runtime package: ``` composer require citomni/cli composer citomni:install:cli ``` Direct equivalent, if you do not use Composer scripts: ``` vendor/bin/citomni-installer install --package=citomni/cli ``` This materializes CLI-owned scaffold such as: ``` bin/citomni config/citomni_cli_cfg.php config/citomni_cli_cfg.dev.php config/citomni_cli_cfg.stage.php config/citomni_cli_cfg.prod.php config/citomni_cli_commands.php config/citomni_cli_commands.dev.php config/citomni_cli_commands.stage.php config/citomni_cli_commands.prod.php config/services_cli.php src/Cli/Command/HelloCommand.php ``` For the full scaffold lifecycle manual, see the [CitOmni Installer README](https://github.com/citomni/installer/blob/main/README.md). --- Add both HTTP and CLI --------------------- [](#add-both-http-and-cli) A combined application can install both modes: ``` composer require citomni/http citomni/cli composer citomni:install:http composer citomni:install:cli ``` HTTP and CLI share the same app root, config folder, common cfg, providers, common services, source layers, language files, and runtime state folders. The mode-specific adapters stay separate: ``` src/Http/ src/Cli/ ``` Shared application logic should normally live in: ``` src/Operation/ src/Repository/ src/Service/ src/Policy/ src/State/ src/Support/ src/Enum/ src/Util/ src/Exception/ ``` For details about installer status checks, repair, sync, conflict handling, manifests, policies, state, and JSON output, see the [CitOmni Installer README](https://github.com/citomni/installer/blob/main/README.md). --- Fresh project layout -------------------- [](#fresh-project-layout) A fresh `citomni/app-skeleton` project contains only the neutral app structure: ``` /app-root /bin /.htaccess /config /.htaccess /citomni_cfg.php /citomni_cfg.dev.php /citomni_cfg.stage.php /citomni_cfg.prod.php /CONFIGURATION.md /providers.php /services.php /language /da /.gitkeep /en /.gitkeep /.htaccess /src /Enum /.gitkeep /Exception /.gitkeep /Operation /.gitkeep /Policy /.gitkeep /Repository /.gitkeep /Service /.gitkeep /State /.gitkeep /Support /.gitkeep /Util /.gitkeep /.htaccess /tests /.htaccess /var /backups /flags /.gitkeep /.gitkeep /cache /.gitkeep /flags /.gitkeep /logs /.gitkeep /nonces /.gitkeep /secrets /.gitkeep /state /.gitkeep /.htaccess .gitattributes .gitignore .htaccess composer.json LICENSE NOTICE README.md TRADEMARKS.md ``` Mode-specific folders such as `public/`, `templates/`, `src/Http/`, and `src/Cli/` are intentionally absent until their owning package is installed and materialized. --- Configuration files ------------------- [](#configuration-files) The neutral skeleton provides the common app-level config entry points. Runtime packages may add mode-specific overlays when HTTP or CLI support is installed. For the detailed merge contract, see [`config/CONFIGURATION.md`](config/CONFIGURATION.md). ### `config/citomni_cfg.php` [](#configcitomni_cfgphp) Defines application-owned common configuration shared by HTTP and CLI. ```