openuispec 0.1.27 → 0.1.29

package/docs/implementation-notes.md

@@ -36,24 +36,57 @@
 
 ## `prepare` command
 
-- `openuispec prepare --target <target>` is the operational bridge between spec drift and AI implementation work.
+- `openuispec prepare --target <target>` is the operational bridge between the spec and AI implementation work.
+- `openuispec configure-target <target>` is the target stack selection step that feeds `prepare`.
+  - it should offer preset defaults for known stacks
+  - it must still allow custom values when the project uses frameworks or libraries outside the catalog
+  - `openuispec init --no-configure-targets` should remain available for users who want to defer target stack decisions until later
+- It should support two modes:
+  1. bootstrap mode when no target snapshot exists yet
+  2. update mode when a target snapshot exists
 - It should be documented as:
-  1. read the target's snapshot baseline
-  2. compute semantic spec changes since that baseline
-  3. produce an AI-ready bundle with likely target scope
+  1. if no snapshot exists, produce a first-time generation bundle from the manifest and current spec files
+  2. if a snapshot exists, compute semantic spec changes since that baseline
+  3. produce the target work bundle with likely target scope
 - Current output includes:
   - project and target
   - output directory
   - likely code roots
-  - baseline commit info
-  - semantic change summary
-  - per-spec-file work items
-  - best-effort candidate target files
+  - mode (`bootstrap` or `update`)
+  - baseline commit info when available
+  - target stack summary from `platform/<target>.yaml`
+  - selected option refs for known preset values
+  - semantic change summary for update mode
+  - per-spec-file work items or first-time generation spec inventory
+  - best-effort candidate target files for update mode
   - next-step guidance
+- Selected option refs should be package-manager oriented, not artifact web pages:
+  - Android: Gradle plugin ids plus `group:artifact:{latest}` library coordinates
+  - Web: npm package specs like `react-router@{latest}`
+  - iOS: package identifiers plus docs links
+- `prepare` must also carry dependency guidance explaining that these refs are anchors only.
+  - AI should add supporting build, plugin, repository, annotation-processing, runtime, dev, and test dependencies required by the chosen stack and current toolchain
+  - AI should resolve exact versions and wiring from current platform docs instead of assuming the preset list is exhaustive
+- Bootstrap mode should surface soft warnings when configured framework/stack values are custom and therefore not covered by preset dependency refs.
+  - these warnings should explain that dependency guidance is incomplete, not silently omit the missing refs
+- Bootstrap mode should also carry explicit generation constraints for the target:
+  - localization rules
+    - use target-native runtime localization resources
+    - forbid in-memory string maps embedded in app code
+  - file structure rules
+    - forbid single-file app output
+    - require separate screen/component/support/resource modules
+  - platform setup rules
+    - refresh current target/framework setup guidance before generation
+    - do not rely on stale memory for project layout, resource wiring, navigation APIs, or packaging conventions
+  - target-specific directory expectations for generated code
+  - backend generation context
+    - if the manifest declares `api.endpoints`, `generation.code_roots.backend` is required
+    - `prepare` should surface the resolved backend root so AI can inspect backend code when generating API clients
 - Important positioning:
   - `prepare` does not generate code
   - `prepare` does not verify code correctness
-  - `prepare` packages the spec delta into scoped implementation work for AI or developers
+  - `prepare` packages either the current spec or the spec delta into scoped implementation work for AI or developers
 
 ## Semantic linting
 
@@ -86,6 +119,7 @@
 - `openuispec status` is the cross-target overview command.
 - Current output includes, per target:
   - output directory
+  - whether the output directory exists
   - snapshot present or missing
   - snapshot timestamp
   - baseline kind / commit / branch
@@ -95,6 +129,7 @@
   - note for missing or legacy snapshots
 - Important positioning:
   - `status` answers "which targets are behind shared spec changes?"
+  - `status` should distinguish "needs generation" from "needs baseline"
   - `status` does not verify code alignment
 - Real-world behavior to document:
   - if `web` was re-snapshotted after the new baseline metadata was added, but `ios` and `android` still have older state files, `status` should show:
@@ -111,5 +146,7 @@
   5. `openuispec prepare --target <target>`
   6. update target UI code
   7. build/run and review
-  8. `openuispec drift --snapshot --target <target>`
+  8. ensure the target output directory exists
+  9. `openuispec drift --snapshot --target <target>`
 - `drift --snapshot` should continue to be described as bookkeeping/baselining, not as proof that the target implementation matches the spec.
+- If the target output directory does not exist yet, the CLI should direct the user to run code generation first instead of implying that snapshot can initialize an empty target.

package/docs/release-notes-v0.1.26.md

@@ -11,7 +11,7 @@ This release expands OpenUISpec as a spec-management and AI-orchestration tool f
   Drift snapshots now record the git baseline commit and branch for each target.
 
 - `openuispec prepare --target <target>`
-  Produces an AI-ready target update bundle with:
+  Produces the target work bundle with:
   - semantic change summary
   - likely code roots
   - candidate target files

package/docs/release-notes-v0.1.28.md

@@ -0,0 +1,25 @@
+# OpenUISpec v0.1.28
+
+This patch supersedes `v0.1.27`.
+
+## Fixes
+
+- Fixed the drift/prepare onboarding dead-end for targets that have not been generated yet.
+  - `drift --snapshot` now keeps the guard against baselining an empty target.
+  - Missing-snapshot guidance now tells users to generate the target output first when the output directory does not exist.
+- Improved `status` to distinguish:
+  - targets that need generation
+  - targets that need a baseline snapshot
+- Updated workflow docs and generated project templates to describe the generation-first requirement before snapshotting.
+- Stabilized the affected CLI tests in this repo by invoking TypeScript entrypoints through the `tsx` loader path instead of the IPC-based binary wrapper.
+
+## Recommended workflow
+
+1. `openuispec validate`
+2. `openuispec validate semantic`
+3. `openuispec status`
+4. `openuispec drift --target <target> --explain`
+5. `openuispec prepare --target <target>`
+6. update target UI
+7. ensure the target output directory exists
+8. `openuispec drift --snapshot --target <target>`

package/docs/stress-test-maturity-report.md

@@ -14,7 +14,7 @@ This assessment stress-tested the project at four layers:
 
 ```bash
 npm ci
-npm run validate                                # from examples/taskflow (workspace script)
+npm run validate                                # from examples/taskflow/openuispec (workspace script)
 npx tsx ../../../schema/validate.ts            # from examples/todo-orbit/openuispec
 npx tsc --noEmit
 for t in ios android web; do

package/drift/index.ts

@@ -73,7 +73,7 @@ export interface ExplainResult {
 
 // ── helpers ───────────────────────────────────────────────────────────
 
-function listFiles(dir: string, ext: string): string[] {
+export function listFiles(dir: string, ext: string): string[] {
   try {
     return readdirSync(dir)
       .filter((f) => f.endsWith(ext))
@@ -106,7 +106,7 @@ function parseSpecDocument(relPath: string, content: string): unknown {
 }
 
 /** Read the status field from a screen or flow YAML file. */
-function readStatus(filePath: string): string {
+export function readStatus(filePath: string): string {
   try {
     const doc = YAML.parse(readFileSync(filePath, "utf-8"));
     if (doc && typeof doc === "object") {
@@ -123,12 +123,12 @@ function readStatus(filePath: string): string {
 }
 
 /** Returns true if a file is a screen or flow (has status semantics). */
-function hasStatusSemantics(relPath: string): boolean {
+export function hasStatusSemantics(relPath: string): boolean {
   const dir = dirname(relPath);
   return dir === "screens" || dir === "flows";
 }
 
-function discoverSpecFiles(projectDir: string): string[] {
+export function discoverSpecFiles(projectDir: string): string[] {
   const manifest = join(projectDir, "openuispec.yaml");
   if (!existsSync(manifest)) {
     console.error(`Error: No openuispec.yaml found in ${projectDir}`);
@@ -434,11 +434,14 @@ export function findProjectDir(cwd: string): string {
   process.exit(1);
 }
 
+/** Read and parse the manifest YAML. */
+export function readManifest(projectDir: string): Record<string, any> {
+  return YAML.parse(readFileSync(join(projectDir, "openuispec.yaml"), "utf-8"));
+}
+
 /** Read the project name from the manifest. */
 export function readProjectName(projectDir: string): string {
-  const doc = YAML.parse(
-    readFileSync(join(projectDir, "openuispec.yaml"), "utf-8")
-  );
+  const doc = readManifest(projectDir);
   return doc.project?.name ?? basename(projectDir);
 }
 
@@ -466,6 +469,26 @@ export function stateFilePath(projectDir: string, projectName: string, target: s
   return join(resolveOutputDir(projectDir, projectName, target), STATE_FILE);
 }
 
+function missingSnapshotMessage(
+  cwd: string,
+  projectDir: string,
+  projectName: string,
+  target: string
+): string {
+  const outDir = resolveOutputDir(projectDir, projectName, target);
+  if (!existsSync(outDir)) {
+    return (
+      `No snapshot found for target "${target}".\n` +
+      `Output directory not found: ${relative(cwd, outDir)}\n` +
+      `Run code generation for "${target}" first, then run: openuispec drift --snapshot --target ${target}`
+    );
+  }
+  return (
+    `No snapshot found for target "${target}".\n` +
+    `Run: openuispec drift --snapshot --target ${target}`
+  );
+}
+
 export function discoverTargets(projectDir: string, projectName: string): string[] {
   const outputDirs = readOutputDirs(projectDir);
   const targets: string[] = [];
@@ -626,10 +649,7 @@ export function loadTargetDrift(
   const projectName = readProjectName(projectDir);
   const statePath = stateFilePath(projectDir, projectName, target);
   if (!existsSync(statePath)) {
-    console.error(
-      `No snapshot found for target "${target}".\n` +
-        `Run: openuispec drift --snapshot --target ${target}`
-    );
+    console.error(missingSnapshotMessage(cwd, projectDir, projectName, target));
     process.exit(1);
   }
 

package/examples/taskflow/AGENTS.md

@@ -0,0 +1,113 @@
+<!-- openuispec-rules-start -->
+<!-- openuispec-rules-version: 0.1.28 -->
+# OpenUISpec — AI Assistant Rules
+# ================================
+# This project uses OpenUISpec to define UI as a semantic spec.
+# Spec files are the single source of truth for all UI across platforms.
+# Targets: "ios", "android", "web"
+
+## IMPORTANT — Read the specification before working with spec files
+
+The spec format, file schemas, and generation rules are defined in the installed `openuispec` package.
+You MUST read the reference files listed below before creating, editing, or generating from any spec file.
+Do NOT guess the file format — skipping this step will produce invalid YAML that fails validation.
+
+**Find the package in this order:**
+1. `node_modules/openuispec/` (project dependency)
+2. Run `npm root -g` → `<prefix>/openuispec/` (global install)
+3. Online: `https://openuispec.rsteam.uz/llms-full.txt` (if not installed)
+
+**Reference files inside the package (read in this order):**
+1. `README.md` — schema tables, file format reference, root wrapper keys
+2. `spec/openuispec-v0.1.md` — full specification (contracts, layout, expressions, adaptive, etc.)
+3. `examples/taskflow/openuispec/` — complete working example with all file types
+4. `schema/` — JSON Schemas for every file type
+
+These files are updated with each package version. Always read from the installed package,
+not from cached or memorized content, to ensure you use the latest spec.
+
+## What is OpenUISpec
+OpenUISpec is a YAML-based spec format that describes an app's UI semantically — tokens, screens, flows, and platform overrides. AI reads the spec and generates native code (SwiftUI, Compose, React). AI reads native code and updates the spec. The spec is the sync layer between platforms.
+
+## Spec location
+- Spec root: `openuispec/`
+- Manifest: `openuispec/openuispec.yaml` — always read this first.
+- Tokens: `openuispec/tokens/`
+- Screens: `openuispec/screens/`
+- Flows: `openuispec/flows/`
+- Contracts: `openuispec/contracts/`
+- Platform: `openuispec/platform/`
+- Locales: `openuispec/locales/`
+
+**Note:** These are the default paths. Actual paths are in `includes:` in `openuispec.yaml` and may use relative paths. Always read `openuispec.yaml` to find the real directories.
+
+## If spec directories are empty (first-time setup)
+This means the project has existing UI code but hasn't been specced yet. Your job:
+
+1. **Read the spec first** — find and read `spec/openuispec-v0.1.md` from the installed package.
+2. **Find existing screens** — scan the codebase for UI screen files.
+3. **Create stubs** — for each screen, create `openuispec/screens/<name>.yaml` with:
+   ```yaml
+   screen_name:
+     semantic: "Brief description of what this screen does"
+     status: stub
+     layout:
+       type: scroll_vertical
+   ```
+4. **Extract tokens** — scan for colors, fonts, spacing and create files in `openuispec/tokens/`.
+5. **Update the manifest** — fill in `data_model`, `api.endpoints`, and `generation.code_roots.backend` in `openuispec/openuispec.yaml`.
+
+## OpenUISpec Source Of Truth
+
+OpenUISpec spec files are the primary source of truth for UI behavior across platforms.
+
+### Start from spec when:
+- the request changes screen structure
+- the request changes navigation
+- the request changes fields, actions, validation, or data binding
+- the request changes tokens, variants, contracts, flows, or localization
+- the request affects more than one platform
+- the request is phrased in product/UI terms rather than platform-code terms
+
+Spec-first workflow:
+1. Read `openuispec/openuispec.yaml` and the relevant spec files first.
+2. Update the spec first.
+3. Update the affected generated/native UI code to match the spec.
+4. Run `openuispec validate`.
+5. Run `openuispec validate semantic`.
+6. Run `openuispec drift --target <target> --explain` to inspect semantic changes since that target's baseline.
+7. Run `openuispec prepare --target <target>` to build the target work bundle for that target. In `bootstrap` mode it provides first-generation constraints; in `update` mode it provides drift-based update scope.
+8. Verify the affected UI targets build/run if possible.
+9. Only then run `openuispec drift --snapshot --target <target>` for affected targets, after that target output directory exists.
+10. Run `openuispec drift --target <target> --explain` again to confirm no spec changes remain for that target.
+11. Use `openuispec status` to see which other targets are still behind the updated spec.
+
+### Start from platform code when:
+- the change is platform-specific polish
+- the change is a local bug fix that does not alter shared semantic behavior
+- the request explicitly asks for an iOS-only, Android-only, or web-only adjustment
+
+Platform-first workflow:
+1. Update native/platform code.
+2. If the change affects shared semantics, sync the spec afterward.
+3. If the change is intentionally platform-specific, document it in `platform/*.yaml` when appropriate.
+
+### Never do this:
+- Do not snapshot drift immediately after changing spec unless the UI code has also been updated.
+- Do not treat `openuispec drift` as proof that generated UI matches the spec.
+- Do not skip `--explain` / `prepare` when another platform needs to catch up with shared spec changes.
+- Do not modify generated UI without checking whether the spec must change first.
+
+## CLI commands
+- `openuispec init` — scaffold a new spec project
+- `openuispec validate [group...]` — validate spec files against schemas
+- `openuispec validate semantic` — run semantic cross-reference linting
+- `openuispec configure-target <t> [--defaults]` — configure target stack defaults
+- `openuispec drift --target <t>` — check for spec drift
+- `openuispec drift --target <t> --explain` — explain semantic spec drift since the target baseline
+- `openuispec drift --snapshot --target <t>` — snapshot current state after the target output exists
+- `openuispec prepare --target <t>` — build the target work bundle
+- `openuispec status` — show cross-target baseline/drift status
+- `openuispec update-rules` — update AI rules to match installed package version
+- `openuispec drift --all` — include stubs in drift check
+<!-- openuispec-rules-end -->

package/examples/taskflow/CLAUDE.md

@@ -0,0 +1,113 @@
+<!-- openuispec-rules-start -->
+<!-- openuispec-rules-version: 0.1.28 -->
+# OpenUISpec — AI Assistant Rules
+# ================================
+# This project uses OpenUISpec to define UI as a semantic spec.
+# Spec files are the single source of truth for all UI across platforms.
+# Targets: "ios", "android", "web"
+
+## IMPORTANT — Read the specification before working with spec files
+
+The spec format, file schemas, and generation rules are defined in the installed `openuispec` package.
+You MUST read the reference files listed below before creating, editing, or generating from any spec file.
+Do NOT guess the file format — skipping this step will produce invalid YAML that fails validation.
+
+**Find the package in this order:**
+1. `node_modules/openuispec/` (project dependency)
+2. Run `npm root -g` → `<prefix>/openuispec/` (global install)
+3. Online: `https://openuispec.rsteam.uz/llms-full.txt` (if not installed)
+
+**Reference files inside the package (read in this order):**
+1. `README.md` — schema tables, file format reference, root wrapper keys
+2. `spec/openuispec-v0.1.md` — full specification (contracts, layout, expressions, adaptive, etc.)
+3. `examples/taskflow/openuispec/` — complete working example with all file types
+4. `schema/` — JSON Schemas for every file type
+
+These files are updated with each package version. Always read from the installed package,
+not from cached or memorized content, to ensure you use the latest spec.
+
+## What is OpenUISpec
+OpenUISpec is a YAML-based spec format that describes an app's UI semantically — tokens, screens, flows, and platform overrides. AI reads the spec and generates native code (SwiftUI, Compose, React). AI reads native code and updates the spec. The spec is the sync layer between platforms.
+
+## Spec location
+- Spec root: `openuispec/`
+- Manifest: `openuispec/openuispec.yaml` — always read this first.
+- Tokens: `openuispec/tokens/`
+- Screens: `openuispec/screens/`
+- Flows: `openuispec/flows/`
+- Contracts: `openuispec/contracts/`
+- Platform: `openuispec/platform/`
+- Locales: `openuispec/locales/`
+
+**Note:** These are the default paths. Actual paths are in `includes:` in `openuispec.yaml` and may use relative paths. Always read `openuispec.yaml` to find the real directories.
+
+## If spec directories are empty (first-time setup)
+This means the project has existing UI code but hasn't been specced yet. Your job:
+
+1. **Read the spec first** — find and read `spec/openuispec-v0.1.md` from the installed package.
+2. **Find existing screens** — scan the codebase for UI screen files.
+3. **Create stubs** — for each screen, create `openuispec/screens/<name>.yaml` with:
+   ```yaml
+   screen_name:
+     semantic: "Brief description of what this screen does"
+     status: stub
+     layout:
+       type: scroll_vertical
+   ```
+4. **Extract tokens** — scan for colors, fonts, spacing and create files in `openuispec/tokens/`.
+5. **Update the manifest** — fill in `data_model`, `api.endpoints`, and `generation.code_roots.backend` in `openuispec/openuispec.yaml`.
+
+## OpenUISpec Source Of Truth
+
+OpenUISpec spec files are the primary source of truth for UI behavior across platforms.
+
+### Start from spec when:
+- the request changes screen structure
+- the request changes navigation
+- the request changes fields, actions, validation, or data binding
+- the request changes tokens, variants, contracts, flows, or localization
+- the request affects more than one platform
+- the request is phrased in product/UI terms rather than platform-code terms
+
+Spec-first workflow:
+1. Read `openuispec/openuispec.yaml` and the relevant spec files first.
+2. Update the spec first.
+3. Update the affected generated/native UI code to match the spec.
+4. Run `openuispec validate`.
+5. Run `openuispec validate semantic`.
+6. Run `openuispec drift --target <target> --explain` to inspect semantic changes since that target's baseline.
+7. Run `openuispec prepare --target <target>` to build the target work bundle for that target. In `bootstrap` mode it provides first-generation constraints; in `update` mode it provides drift-based update scope.
+8. Verify the affected UI targets build/run if possible.
+9. Only then run `openuispec drift --snapshot --target <target>` for affected targets, after that target output directory exists.
+10. Run `openuispec drift --target <target> --explain` again to confirm no spec changes remain for that target.
+11. Use `openuispec status` to see which other targets are still behind the updated spec.
+
+### Start from platform code when:
+- the change is platform-specific polish
+- the change is a local bug fix that does not alter shared semantic behavior
+- the request explicitly asks for an iOS-only, Android-only, or web-only adjustment
+
+Platform-first workflow:
+1. Update native/platform code.
+2. If the change affects shared semantics, sync the spec afterward.
+3. If the change is intentionally platform-specific, document it in `platform/*.yaml` when appropriate.
+
+### Never do this:
+- Do not snapshot drift immediately after changing spec unless the UI code has also been updated.
+- Do not treat `openuispec drift` as proof that generated UI matches the spec.
+- Do not skip `--explain` / `prepare` when another platform needs to catch up with shared spec changes.
+- Do not modify generated UI without checking whether the spec must change first.
+
+## CLI commands
+- `openuispec init` — scaffold a new spec project
+- `openuispec validate [group...]` — validate spec files against schemas
+- `openuispec validate semantic` — run semantic cross-reference linting
+- `openuispec configure-target <t> [--defaults]` — configure target stack defaults
+- `openuispec drift --target <t>` — check for spec drift
+- `openuispec drift --target <t> --explain` — explain semantic spec drift since the target baseline
+- `openuispec drift --snapshot --target <t>` — snapshot current state after the target output exists
+- `openuispec prepare --target <t>` — build the target work bundle
+- `openuispec status` — show cross-target baseline/drift status
+- `openuispec update-rules` — update AI rules to match installed package version
+- `openuispec drift --all` — include stubs in drift check
+<!-- openuispec-rules-end -->

package/examples/taskflow/backend/.gitkeep

@@ -0,0 +1 @@
+

package/examples/taskflow/generated/android/TaskFlow/README.md

@@ -0,0 +1,43 @@
+# TaskFlow Android Target
+
+This Android target was generated directly from the local `openuispec/` TaskFlow specification, without copying another sample project's output.
+
+## What is included
+
+- A lean Jetpack Compose app scaffold under `app/`
+- Adaptive navigation using spec breakpoints:
+  - `compact`: bottom navigation
+  - `regular` and `expanded`: navigation rail
+- Spec-derived screens:
+  - Home
+  - Task detail
+  - Projects
+  - Project detail
+  - Calendar stub
+  - Settings
+  - Profile edit
+- Spec-derived flows:
+  - Create task
+  - Edit task
+  - Assign task
+  - New project
+- Local sample data matching the spec's data model
+- English string resources derived from `openuispec/locales/en.json`
+- Theme colors based on `openuispec/tokens/color.yaml` and `themes.yaml`
+
+## Project notes
+
+- This is intentionally lean. It favors clear generated structure over a fully productionized architecture.
+- The app uses local Compose state instead of wiring real API clients.
+- The media-player custom contract is acknowledged in the spec but not implemented here because no screen in this minimal target renders a concrete media attachment asset.
+- No Gradle wrapper is checked in. Use a local Gradle installation or import the project into Android Studio and let it create the wrapper if needed.
+
+## Suggested verification
+
+From this directory:
+
+```bash
+gradle :app:assembleDebug
+```
+
+Or open `generated/android/TaskFlow` in Android Studio and run the app on an emulator.

package/examples/taskflow/generated/android/TaskFlow/app/build.gradle.kts

@@ -0,0 +1,76 @@
+plugins {
+    id("com.android.application")
+    id("org.jetbrains.kotlin.android")
+    id("org.jetbrains.kotlin.plugin.compose")
+}
+
+import org.jetbrains.kotlin.gradle.dsl.JvmTarget
+
+android {
+    namespace = "uz.rsteam.taskflow"
+    compileSdk = 35
+
+    defaultConfig {
+        applicationId = "uz.rsteam.taskflow"
+        minSdk = 26
+        targetSdk = 35
+        versionCode = 1
+        versionName = "1.0.0"
+
+        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
+        vectorDrawables {
+            useSupportLibrary = true
+        }
+    }
+
+    buildTypes {
+        release {
+            isMinifyEnabled = false
+            proguardFiles(
+                getDefaultProguardFile("proguard-android-optimize.txt"),
+                "proguard-rules.pro"
+            )
+        }
+    }
+
+    compileOptions {
+        sourceCompatibility = JavaVersion.VERSION_17
+        targetCompatibility = JavaVersion.VERSION_17
+    }
+
+    buildFeatures {
+        compose = true
+    }
+
+    packaging {
+        resources {
+            excludes += "/META-INF/{AL2.0,LGPL2.1}"
+        }
+    }
+}
+
+kotlin {
+    compilerOptions {
+        jvmTarget.set(JvmTarget.JVM_17)
+    }
+}
+
+dependencies {
+    val composeBom = platform("androidx.compose:compose-bom:2024.10.01")
+
+    implementation(composeBom)
+    androidTestImplementation(composeBom)
+
+    implementation("androidx.core:core-ktx:1.15.0")
+    implementation("androidx.lifecycle:lifecycle-runtime-ktx:2.8.7")
+    implementation("androidx.activity:activity-compose:1.9.3")
+    implementation("androidx.compose.ui:ui")
+    implementation("androidx.compose.ui:ui-graphics")
+    implementation("androidx.compose.ui:ui-tooling-preview")
+    implementation("androidx.compose.material3:material3")
+    implementation("androidx.compose.material:material-icons-extended")
+    implementation("androidx.compose.foundation:foundation")
+
+    debugImplementation("androidx.compose.ui:ui-tooling")
+    debugImplementation("androidx.compose.ui:ui-test-manifest")
+}

package/examples/taskflow/generated/android/TaskFlow/app/proguard-rules.pro

@@ -0,0 +1 @@
+# Generated sample app. No custom ProGuard rules required.

package/examples/taskflow/generated/android/TaskFlow/app/src/main/AndroidManifest.xml

@@ -0,0 +1,21 @@
+<?xml version="1.0" encoding="utf-8"?>
+<manifest xmlns:android="http://schemas.android.com/apk/res/android">
+
+    <application
+        android:allowBackup="true"
+        android:label="@string/app_name"
+        android:supportsRtl="true"
+        android:theme="@style/Theme.TaskFlow">
+        <activity
+            android:name=".MainActivity"
+            android:exported="true"
+            android:theme="@style/Theme.TaskFlow">
+            <intent-filter>
+                <action android:name="android.intent.action.MAIN" />
+
+                <category android:name="android.intent.category.LAUNCHER" />
+            </intent-filter>
+        </activity>
+    </application>
+
+</manifest>

package/examples/taskflow/generated/android/TaskFlow/app/src/main/java/uz/rsteam/taskflow/MainActivity.kt

@@ -0,0 +1,19 @@
+package uz.rsteam.taskflow
+
+import android.os.Bundle
+import androidx.activity.ComponentActivity
+import androidx.activity.compose.setContent
+import androidx.activity.enableEdgeToEdge
+import uz.rsteam.taskflow.ui.theme.TaskFlowTheme
+
+class MainActivity : ComponentActivity() {
+    override fun onCreate(savedInstanceState: Bundle?) {
+        super.onCreate(savedInstanceState)
+        enableEdgeToEdge()
+        setContent {
+            TaskFlowTheme {
+                TaskFlowApp()
+            }
+        }
+    }
+}