novahiz 0.1.0

package/bundled-skills/dart-resolve-package-conflicts/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: dart-resolve-package-conflicts
+description: Workflow for fixing package version conflicts. Use this when `pub get` fails due to incompatible package versions.
+metadata:
+  model: models/gemini-3.1-pro-preview
+  last_modified: Fri, 24 Apr 2026 15:11:14 GMT
+---
+# Managing Dart Dependencies
+
+## Contents
+- [Core Concepts](#core-concepts)
+- [Version Constraints](#version-constraints)
+- [Workflow: Auditing Dependencies](#workflow-auditing-dependencies)
+- [Workflow: Upgrading Dependencies](#workflow-upgrading-dependencies)
+- [Workflow: Resolving Version Conflicts](#workflow-resolving-version-conflicts)
+- [Examples](#examples)
+
+## Core Concepts
+
+Dart enforces a strict single-version rule for dependencies: a project and all its transitive dependencies must resolve to a single, shared version of any given package. This prevents runtime type mismatches but introduces the risk of "version lock."
+
+To mitigate version lock, Dart relies on version constraints rather than pinned versions in the `pubspec.yaml`. The `pubspec.lock` file maintains the exact resolved versions for reproducible builds.
+
+Understand the output columns of `dart pub outdated`:
+*   **Current:** The version currently recorded in `pubspec.lock`.
+*   **Upgradable:** The latest version allowed by the constraints in `pubspec.yaml`. `dart pub upgrade` resolves to this.
+*   **Resolvable:** The absolute latest version that can be resolved when factoring in all other dependencies in the project.
+*   **Latest:** The latest published version of the package (excluding prereleases).
+
+## Version Constraints
+
+*   **Use Caret Syntax:** Always use caret syntax (e.g., `^1.2.3`) for dependencies in `pubspec.yaml`. This allows `pub` to select newer, non-breaking versions (up to, but not including, the next major version) during resolution.
+*   **Tighten Dev Dependencies:** Set the lower bound of `dev_dependencies` to the exact version currently used. This reduces resolution complexity and prevents older, incompatible dev tools from being selected.
+*   **Enforce Lockfiles in CI:** Use `dart pub get --enforce-lockfile` in CI/CD pipelines to ensure the exact versions tested locally are used in production.
+
+## Workflow: Auditing Dependencies
+
+Run this workflow periodically to identify stale packages that may impact stability or performance.
+
+**Task Progress:**
+- [ ] Run `dart pub outdated`.
+- [ ] Review the **Upgradable** column to identify packages that can be updated without modifying `pubspec.yaml`.
+- [ ] Review the **Resolvable** column to identify packages that require constraint modifications in `pubspec.yaml` to update.
+- [ ] Identify any packages marked as retracted or discontinued.
+
+## Workflow: Upgrading Dependencies
+
+Use conditional logic based on the audit results to upgrade dependencies.
+
+**Task Progress:**
+- [ ] **If updating to "Upgradable" versions:**
+  - [ ] Run `dart pub upgrade`.
+  - [ ] Run `dart pub upgrade --tighten` to automatically update the lower bounds in `pubspec.yaml` to match the newly resolved versions.
+- [ ] **If updating to "Resolvable" versions (Major updates):**
+  - [ ] Manually edit `pubspec.yaml` to bump the version constraint to match the "Resolvable" column (e.g., change `^0.11.0` to `^0.12.1`).
+  - [ ] Run `dart pub upgrade` to resolve the new constraints and update `pubspec.lock`.
+- [ ] **Feedback Loop:**
+  - [ ] Run `dart analyze` -> review errors -> fix breaking API changes.
+  - [ ] Run `dart test` -> review failures -> fix regressions.
+
+## Workflow: Resolving Version Conflicts
+
+When `pub` cannot find a set of concrete versions that satisfy all constraints, or when dealing with a retracted package version, manipulate the lockfile surgically.
+
+**NEVER** delete the entire `pubspec.lock` file and run `dart pub get`. This causes uncontrolled upgrades across the entire dependency graph.
+
+**Task Progress:**
+- [ ] Open `pubspec.lock`.
+- [ ] Locate the specific YAML block for the conflicting or retracted package.
+- [ ] Delete ONLY that package's entry from the lockfile.
+- [ ] Run `dart pub get` to fetch the newest compatible, non-retracted version for that specific package.
+- [ ] **Feedback Loop:**
+  - [ ] Run `dart pub deps` -> verify the dependency graph resolves correctly.
+  - [ ] If resolution fails, identify the transitive dependency causing the lock, update its constraint in `pubspec.yaml`, and retry.
+
+## Examples
+
+### Tightening Constraints
+When `dart pub outdated` shows a package is resolvable to a higher minor/patch version, use the `--tighten` flag to update the `pubspec.yaml` automatically.
+
+**Input (`pubspec.yaml`):**
+```yaml
+dependencies:
+  http: ^0.13.0
+```
+
+**Command:**
+```bash
+dart pub upgrade --tighten http
+```
+
+**Output (`pubspec.yaml`):**
+```yaml
+dependencies:
+  http: ^0.13.5
+```
+
+### Surgical Lockfile Removal
+If `package_a` is retracted or locked in a conflict, remove only its block from `pubspec.lock`.
+
+**Before (`pubspec.lock`):**
+```yaml
+packages:
+  package_a:
+    dependency: "direct main"
+    description:
+      name: package_a
+      url: "https://pub.dev"
+    source: hosted
+    version: "1.0.0" # Retracted version
+  package_b:
+    dependency: "direct main"
+    # ...
+```
+
+**Action:** Delete the `package_a` block entirely. Leave `package_b` untouched. Run `dart pub get`.

package/bundled-skills/dart-run-static-analysis/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: dart-run-static-analysis
+description: Execute `dart analyze` to identify warnings and errors, and use `dart fix --apply` to automatically resolve mechanical lint issues. Use during development to ensure code quality and before committing changes.
+metadata:
+  model: models/gemini-3.1-pro-preview
+  last_modified: Fri, 24 Apr 2026 15:09:34 GMT
+---
+# Analyzing and Fixing Dart Code
+
+## Contents
+- [Analysis Configuration](#analysis-configuration)
+- [Diagnostic Suppression](#diagnostic-suppression)
+- [Workflow: Executing Static Analysis](#workflow-executing-static-analysis)
+- [Workflow: Applying Automated Fixes](#workflow-applying-automated-fixes)
+- [Examples](#examples)
+
+## Analysis Configuration
+
+Configure the Dart analyzer using the `analysis_options.yaml` file located at the package root.
+
+- **Base Configuration:** Always include a standard rule set (e.g., `package:lints/recommended.yaml` or `package:flutter_lints/flutter.yaml`) using the `include:` directive.
+- **Strict Type Checks:** Enable strict type checks under the `analyzer: language:` node to prevent implicit downcasts and dynamic inferences. Set `strict-casts: true`, `strict-inference: true`, and `strict-raw-types: true`.
+- **Linter Rules:** Explicitly enable or disable specific rules under the `linter: rules:` node. Use a key-value map (`rule_name: true/false`) when overriding included rules, or a list (`- rule_name`) when defining a fresh set. Do not mix list and map syntax in the same `rules` block.
+- **Formatter Configuration:** Configure `dart format` behavior under the `formatter:` node. Set `page_width` (default 80) and `trailing_commas` (`automate` or `preserve`).
+- **Analyzer Plugins:** Enable custom diagnostics by adding plugins under the `analyzer: plugins:` node. Ensure the plugin package is added as a `dev_dependency` in `pubspec.yaml`.
+
+## Diagnostic Suppression
+
+When a diagnostic (lint or warning) yields a false positive or applies to generated code, suppress it explicitly.
+
+- **File-level Exclusion:** Use the `analyzer: exclude:` node in `analysis_options.yaml` to exclude entire files or directories (e.g., `**/*.g.dart`) using glob patterns.
+- **File-level Suppression:** Add `// ignore_for_file: <diagnostic_code>` at the top of a Dart file to suppress specific diagnostics for the entire file. Use `// ignore_for_file: type=lint` to suppress all linter rules.
+- **Line-level Suppression:** Add `// ignore: <diagnostic_code>` on the line directly above the offending code, or appended to the end of the offending line.
+- **Pubspec Suppression:** Add `# ignore: <diagnostic_code>` above the offending line in `pubspec.yaml` files (e.g., `# ignore: sort_pub_dependencies`).
+- **Plugin Diagnostics:** Prefix the diagnostic code with the plugin name when suppressing plugin-specific issues (e.g., `// ignore: some_plugin/some_code`).
+
+## Workflow: Executing Static Analysis
+
+Use this workflow to identify type-related bugs, style violations, and potential runtime errors.
+
+**Task Progress:**
+- [ ] 1. Verify `analysis_options.yaml` exists at the project root.
+- [ ] 2. Run the analyzer using the `analyze_files` MCP tool (if available) or the CLI command `dart analyze <target_directory>`.
+- [ ] 3. Review the diagnostic output.
+- [ ] 4. If info-level issues must be treated as failures, append the `--fatal-infos` flag.
+- [ ] 5. Resolve reported errors manually or proceed to the Automated Fixes workflow.
+
+## Workflow: Applying Automated Fixes
+
+Use this workflow to resolve outdated API usages, apply quick fixes, and migrate code (e.g., Dart 3 migrations).
+
+**Task Progress:**
+- [ ] 1. Execute a dry run to preview proposed changes using the `dart_fix` MCP tool or CLI command `dart fix --dry-run`.
+- [ ] 2. Review the proposed fixes to ensure they align with the intended architecture.
+- [ ] 3. If additional fixes are required, verify that the corresponding linter rules are enabled in `analysis_options.yaml`.
+- [ ] 4. Apply the fixes using the `dart_fix` MCP tool or CLI command `dart fix --apply`.
+- [ ] 5. Format the modified code using the `dart_format` MCP tool or CLI command `dart format .`.
+- [ ] 6. Run the static analysis workflow to verify all diagnostics are resolved.
+
+## Examples
+
+### Comprehensive `analysis_options.yaml`
+
+```yaml
+include: package:flutter_lints/recommended.yaml
+
+analyzer:
+  exclude:
+    - "**/*.g.dart"
+    - "lib/generated/**"
+  language:
+    strict-casts: true
+    strict-inference: true
+    strict-raw-types: true
+  errors:
+    todo: ignore
+    invalid_assignment: warning
+    missing_return: error
+
+linter:
+  rules:
+    avoid_shadowing_type_parameters: false
+    await_only_futures: true
+    use_super_parameters: true
+
+formatter:
+  page_width: 100
+  trailing_commas: preserve
+```
+
+### Inline Diagnostic Suppression
+
+```dart
+// Suppress for the entire file
+// ignore_for_file: unused_local_variable, dead_code
+
+void processData() {
+  // Suppress for a specific line
+  // ignore: invalid_assignment
+  int x = '';
+  
+  const y = 10; // ignore: constant_identifier_names
+}
+```

package/bundled-skills/dart-setup-ffi-assets/SKILL.md

@@ -0,0 +1,419 @@
+---
+name: dart-setup-ffi-assets
+description: "Guides agents in compiling and packaging C/C++ source code into dynamic or static libraries (Code Assets) using Dart's Native Assets hook system (via hook/build.dart and hook/link.dart utilizing package:hooks and package:native_toolchain_c). Use when a user asks to: 'setup native assets', 'compile C/C++ source code', 'bundle dynamic libraries', 'build native C code', 'link native assets', 'implement build.dart or link.dart hooks', or 'integrate C/C++ interop in Dart/Flutter'. Helps agents avoid manual toolchain orchestration and configures secure hash-validated binary downloads or advanced linker tree-shaking with package:record_use mapping."
+metadata:
+  model: models/gemini-3.1-pro-preview
+  last_modified: Fri, 29 May 2026 09:10:00 GMT
+---
+# Compiling C Code into Code Assets with Native Assets Hooks
+
+Integrate and automate the compilation and packaging of native C/C++ source code into **Code Assets** under Dart's overarching **Native Assets** feature using build and link hooks.
+
+## Contents
+- [Introduction](#introduction)
+- [Constraints](#constraints)
+- [Native Interop Packages](#native-interop-packages)
+- [Step-by-Step Workflow](#step-by-step-workflow)
+- [Choosing an Integration Approach](#choosing-an-integration-approach)
+- [Method 1: Local Compilation with Linker Tree-Shaking (Recommended)](#method-1-local-compilation-with-linker-tree-shaking-recommended)
+  - [Prerequisite Host Compiler Toolchains](#prerequisite-host-compiler-toolchains)
+  - [C Source and Bindings Setup](#c-source-and-bindings-setup)
+  - [Defining the C Library Build Spec](#defining-the-c-library-build-spec)
+  - [Implementing hook/build.dart](#implementing-hookbuilddart)
+  - [Implementing hook/link.dart](#implementing-hooklinkdart)
+- [Method 2: Downloading Precompiled Dynamic Libraries](#method-2-downloading-precompiled-dynamic-libraries)
+  - [Why Download Precompiled Binaries?](#why-download-precompiled-binaries)
+  - [Implementing Precompiled Dynamic Downloads](#implementing-precompiled-dynamic-downloads)
+- [Verification Checklist](#verification-checklist)
+  - [1. Local Execution Sandbox](#1-local-execution-sandbox)
+  - [2. Verify Target Outputs](#2-verify-target-outputs)
+  - [3. Verify Tree-Shaking Stripping](#3-verify-tree-shaking-stripping)
+  - [4. Verify Offline Compliance (User Defines)](#4-verify-offline-compliance-user-defines)
+
+---
+
+## Introduction
+
+Under Dart's **Native Assets** feature, packages can package native code (like C/C++ libraries) as **Code Assets** and bundle them automatically during standard development cycles (e.g., `dart run`, `dart test`, `dart build`, and `flutter run`). The packaging of **Code Assets** is driven by two programmatic hook scripts placed inside a package's `hook/` folder:
+
+1.  `hook/build.dart`: Compiles local C sources to machine code or bundles prebuilt native binaries as code assets for a specific host/target architecture.
+2.  `hook/link.dart`: Links built code assets, applying advanced tree-shaking optimizations to strip unused native symbols and compress the runtime binary size.
+
+---
+
+## Constraints
+
+> [!IMPORTANT]
+> Keep all file resolving platform-independent. Never hardcode absolute target paths, shell scripts, or system command variables. Always use `Platform.script.resolve()` or `Uri`-based resolution to ensure scripts are fully portable.
+
+*   **Hook Locations**: Compiling and packaging hooks must reside strictly inside the `hook/` directory at the package's root:
+    *   `hook/build.dart` (Build execution phase)
+    *   `hook/link.dart` (Optional packaging/linking/tree-shaking phase)
+*   **Compile Toolchain Standard**: Use the programmatic APIs from `package:native_toolchain_c` (e.g. `CBuilder` and `CLibrary`) to run compile toolchains. Never invoke raw `gcc`, `clang`, or `msvc` via shell commands.
+*   **Preamble & License Headers**: Every handcrafted and generated source file (including bindings, helpers, and hooks) must strictly contain the target package's copyright and licensing header.
+*   **Tree Shaking Mapping**: If utilizing compiler tree-shaking, you must map the target Dart method names (e.g. `Method.name`) back to their raw native C symbol names using a record use mapping generated by FFIgen. The mapping file must reside under `lib/src/third_party/` and strictly use the `.g.dart` extension (e.g., `sqlite3.record_use_mapping.g.dart`).
+*   **Integrity Safeguards for Precompiled Libraries**: If adopting the dynamic download pattern:
+    *   **Cryptographic Verification**: Downloaded prebuilt binaries must be checked against preconfigured lookup tables containing MD5 or SHA-256 hashes to guarantee binary integrity and prevent tampering.
+    *   **Graceful Recovery**: Support offline developers by providing fallbacks (such as local compiler execution via flags like `local_build`).
+
+---
+
+## Native Interop Packages
+
+Programmatic build and link hooks for **Code Assets** leverage three specialized native interop packages:
+
+| Dependency | Purpose | Key API Abstractions |
+| :--- | :--- | :--- |
+| **`package:hooks`** | Main orchestrator defining execution bounds. | `build(args, callback)`, `link(args, callback)` |
+| **`package:native_toolchain_c`** | Detects local compilers (MSVC, Xcode/Clang, GCC) and executes build toolchains. | `CLibrary`, `CBuilder`, `LinkerOptions.treeshake` |
+| **`package:code_assets`** | Models code metadata records passed to dynamic loaders. | `CodeAsset`, `DynamicLoadingBundled` |
+
+---
+
+## Step-by-Step Workflow
+
+### Step 1: Add Dependencies
+Add Code Assets hook and toolchain dependencies to your package. You must fetch these dependencies directly from **pub.dev**.
+
+You can add it automatically using the CLI:
+```bash
+dart pub add code_assets hooks native_toolchain_c record_use dev:ffigen
+```
+
+Or manually declare them in your target package's `pubspec.yaml`:
+```yaml
+dependencies:
+  code_assets: ^1.0.0
+  hooks: ^0.1.0
+  native_toolchain_c: ^0.1.0
+  record_use: ^0.6.0
+
+dev_dependencies:
+  ffigen: ^20.1.1
+```
+
+### Step 2: Define C Specifications
+Define your target C library compilation metadata inside `lib/src/c_library.dart`. This lets both the build and link hooks share a single source of truth for assets, names, and sources.
+
+### Step 3: Implement Build and Link Hook Scripts
+Write the compilation orchestration script inside `hook/build.dart` and the dead-code elimination logic inside `hook/link.dart`.
+
+### Step 4: Run the Hook Cycle
+Running standard test suites dynamically launches the build and link hook lifecycle in the background:
+```bash
+dart test
+```
+
+---
+
+## Choosing an Integration Approach
+
+There are two primary methods for integrating and delivering C/C++ native assets in Dart. Select the one that matches your project requirements:
+
+| Aspect | Method 1: Local Compilation & Tree-Shaking | Method 2: Precompiled Downloads |
+| :--- | :--- | :--- |
+| **Primary Use Case** | When C/C++ source code is included directly in the package and you want maximum size optimization. | When compiling locally is slow/complex, or when avoiding developer host toolchain requirements. |
+| **Host Toolchain Requirements** | Requires pre-installed platform C compiler (Xcode tools, MSVC, GCC). | Zero compiler setup required on developer/user machines. |
+| **Binary Optimization** | Premium. Unused symbols are completely tree-shaken, decreasing library size. | Standard. Standard compiled binaries are shipped as-is. |
+| **Offline Setup** | Fully compliant. Works completely offline. | Requires network access to download libraries, with offline fallback. |
+
+---
+
+## Method 1: Local Compilation with Linker Tree-Shaking (Recommended)
+
+In this approach, the build hook invokes local toolchains (GCC, Clang, MSVC) to compile source files directly. The link hook subsequently filters output symbols utilizing compiler options, retaining only target methods invoked in user code. This represents the standard, robust SQLite pattern under `pkgs/code_assets/example/sqlite`.
+
+### Prerequisite Host Compiler Toolchains
+
+Since `package:native_toolchain_c` delegates actual dynamic compilation to the host operating system's default toolchain, the development machine **must** have one of the following compiler packages pre-installed:
+
+*   **macOS**: Xcode Command Line Tools. Install via:
+    ```bash
+    xcode-select --install
+    ```
+*   **Linux**: GCC or Clang. Install via:
+    ```bash
+    sudo apt install build-essential
+    ```
+*   **Windows**: MSVC (Microsoft Visual C++). Install the **Visual Studio Installer** and select the **Desktop development with C++** workload.
+
+*Note: If no compatible toolchain is discovered on the host path, the build hook script will throw a compilation execution exception. Ensure to specify compiler constraints or adopt Method 2 if toolchains cannot be guaranteed.*
+
+### C Source and Bindings Setup
+
+Assume a C source defining simple math functions at `third_party/sqlite/sqlite3.c` with its entry point header at `third_party/sqlite/sqlite3.h`:
+
+```c
+#ifndef SQLITE3_H_
+#define SQLITE3_H_
+
+const char *sqlite3_libversion(void);
+
+#endif // SQLITE3_H_
+```
+
+We utilize a programmatic FFIgen script (`tool/ffigen.dart`) to create FFI bindings in `lib/src/third_party/sqlite3.g.dart`, enabling recorded usage tracking and producing the lookup metadata map in `lib/src/third_party/sqlite3.record_use_mapping.g.dart`:
+
+```dart
+// AUTO-GENERATED FILE - DO NOT MODIFY.
+// Generated via ffigen.
+
+const recordUseMapping = {
+  'sqlite3_libversion': 'sqlite3_libversion',
+};
+```
+
+### Defining the C Library Build Spec
+
+Define the centralized library specification in `lib/src/c_library.dart`:
+
+```dart
+import 'package:native_toolchain_c/native_toolchain_c.dart';
+
+/// The C build specification for the sqlite library.
+final cLibrary = CLibrary(
+  name: 'sqlite3',
+  assetName: 'src/third_party/sqlite3.g.dart',
+  sources: ['third_party/sqlite/sqlite3.c'],
+);
+```
+
+### Implementing `hook/build.dart`
+
+Implement `hook/build.dart` using `CLibrary.build`. This builds the library to a dynamic library (e.g. `.so`, `.dylib`, or `.dll`) inside the hook's target directory:
+
+```dart
+import 'package:code_assets/code_assets.dart';
+import 'package:hooks/hooks.dart';
+import 'package:sqlite/src/c_library.dart';
+
+void main(List<String> args) async {
+  await build(args, (input, output) async {
+    if (input.config.buildCodeAssets) {
+      await cLibrary.build(
+        input: input,
+        output: output,
+        defines: {
+          if (input.config.code.targetOS == OS.windows)
+            // Ensure C functions are explicitly exported in the Windows DLL
+            'SQLITE_API': '__declspec(dllexport)',
+        },
+      );
+    }
+  });
+}
+```
+
+### Implementing `hook/link.dart`
+
+Implement the link optimization phase in `hook/link.dart`. This utilizes compiler tree-shaking options (`LinkerOptions.treeshake`) to compile a minimized, dead-code-eliminated binary based on symbol usage records:
+
+```dart
+import 'package:hooks/hooks.dart';
+import 'package:native_toolchain_c/native_toolchain_c.dart';
+import 'package:record_use/record_use.dart';
+import 'package:sqlite/src/c_library.dart';
+import 'package:sqlite/src/third_party/sqlite3.record_use_mapping.g.dart';
+
+void main(List<String> arguments) async {
+  await link(arguments, (input, output) async {
+    await cLibrary.link(
+      input: input,
+      output: output,
+      linkerOptions: LinkerOptions.treeshake(
+        // Map Dart Method references back to raw C symbol names
+        symbolsToKeep: input.recordedUses?.calls.keys.cast<Method>().map(
+          (e) => recordUseMapping[e.name]!,
+        ),
+      ),
+    );
+  });
+}
+```
+
+---
+
+## Method 2: Downloading Precompiled Dynamic Libraries
+
+An alternative approach compiles binaries beforehand on a central build machine, archives them, and downloads the target binary during the build hook execution. This matches the paradigm demonstrated in the `download_asset` hook package.
+
+### Why Download Precompiled Binaries?
+
+*   **Host Constraints**: Compiling large C/C++ libraries locally requires a complete compiler setup (GCC, Xcode/SDKs, Visual Studio) that the end-developer's host machine may not possess.
+*   **Compile Speed**: Precompiled downloads execute in milliseconds compared to potentially long multi-minute compilation processes.
+*   **Platform Bridging**: Allows cross-compiling constraints to be avoided if host architectures are limited.
+
+---
+
+### Implementing Precompiled Dynamic Downloads
+
+We configure our build hook to detect local compiler flags (e.g. `local_build`). If not specified, the hook utilizes `HttpClient` to pull down platform-specific libraries, calculates the MD5 hash to confirm download safety against a configured hashes lookup table, and registers the binary file as a `CodeAsset`:
+
+#### 1. Defining Target Hashes (`lib/src/hook_helpers/hashes.dart`)
+Define target MD5 hash checks per platform file in your package sources:
+
+```dart
+const assetHashes = {
+  'libnative_add_macos_arm64.dylib': '4a88f50438a98402db2dbd47b59eb412',
+  'libnative_add_linux_x64.so': '9f5e15043aa98402dcdbbd47b59ea520',
+  'native_add_windows_x64.dll': 'a881e5043ba98402acdebd47b59fa321',
+};
+```
+
+#### 2. Hook Downloader Helper (`lib/src/hook_helpers/download.dart`)
+Implement the downloading and integrity check logic using dynamic target filename matching:
+
+```dart
+import 'dart:io';
+import 'package:code_assets/code_assets.dart';
+import 'package:crypto/crypto.dart';
+
+const version = '1.0.0';
+
+Uri downloadUri(String target) => Uri.parse(
+  'https://github.com/my-org/my-native-repo/releases/download/$version/$target',
+);
+
+Future<File> downloadAsset(
+  OS targetOS,
+  Architecture targetArchitecture,
+  Directory outputDir,
+) async {
+  final fileName = targetOS.dylibFileName('native_add_${targetOS.name}_${targetArchitecture.name}');
+  final uri = downloadUri(fileName);
+  
+  final client = HttpClient()..findProxy = HttpClient.findProxyFromEnvironment;
+  final request = await client.getUrl(uri);
+  final response = await request.close();
+  
+  if (response.statusCode != 200) {
+    throw ArgumentError('Download target $uri failed: Code ${response.statusCode}');
+  }
+  
+  final targetFile = File.fromUri(outputDir.uri.resolve(fileName));
+  await targetFile.create(recursive: true);
+  await response.pipe(targetFile.openWrite());
+  
+  return targetFile;
+}
+
+Future<String> hashAsset(File file) async {
+  return md5.convert(await file.readAsBytes()).toString();
+}
+```
+
+#### 3. Implementing `hook/build.dart`
+
+Write the final download build hook incorporating local compilation fallback:
+
+```dart
+import 'dart:io';
+import 'package:code_assets/code_assets.dart';
+import 'package:hooks/hooks.dart';
+import 'package:my_download_package/src/hook_helpers/hashes.dart';
+import 'package:my_download_package/src/hook_helpers/download.dart';
+import 'package:native_toolchain_c/native_toolchain_c.dart';
+
+void main(List<String> args) async {
+  await build(args, (input, output) async {
+    final localBuild = input.userDefines['local_build'] as bool? ?? false;
+
+    if (localBuild) {
+      final name = 'native_add_${input.config.code.targetOS.name}_${input.config.code.targetArchitecture.name}';
+      final builder = CBuilder.library(
+        name: name,
+        assetName: 'native_add.dart',
+        sources: ['src/native_add.c'],
+      );
+      await builder.run(input: input, output: output);
+    } else {
+      final targetOS = input.config.code.targetOS;
+      final targetArch = input.config.code.targetArchitecture;
+      final outputDir = Directory.fromUri(input.outputDirectory);
+
+      final file = await downloadAsset(targetOS, targetArch, outputDir);
+
+      final fileHash = await hashAsset(file);
+      final expectedFileName = targetOS.dylibFileName('native_add_${targetOS.name}_${targetArch.name}');
+      final expectedHash = assetHashes[expectedFileName];
+
+      if (fileHash != expectedHash) {
+        throw Exception(
+          'Security Mismatch: File $expectedFileName hash verification failed! '
+          'Found hash: $fileHash, expected: $expectedHash.'
+        );
+      }
+
+      output.assets.code.add(
+        CodeAsset(
+          package: input.packageName,
+          name: 'native_add.dart',
+          linkMode: DynamicLoadingBundled(),
+          file: file.uri,
+        ),
+      );
+    }
+  });
+}
+```
+
+---
+
+## Verification Checklist
+
+Before declaring a build or link hook implementation complete, always perform the following checks:
+
+### 1. Local Execution Sandbox
+Run unit tests and confirm the native assets compile/link process completes with no runtime or build tool exceptions:
+```bash
+dart test
+```
+
+### 2. Verify Target Outputs
+Navigate to your package target directory and verify that dynamic binary assets are created for the host system:
+*   **macOS**: Verify `.dart_tool/resources/` or target directories contain `.dylib` files.
+*   **Linux**: Verify `.dart_tool/resources/` or target directories contain `.so` files.
+*   **Windows**: Verify `.dart_tool/resources/` or target directories contain `.dll` files.
+
+### 3. Verify Tree-Shaking Stripping
+To ensure the link hook is actually stripping unused native symbols and compressing binary packaging, perform the following validation:
+
+1. Compile a production bundle of the CLI/app:
+   ```bash
+   dart build cli bin/main.dart
+   ```
+2. Navigate to the compiled build directory containing the dynamic library.
+3. Query the exported dynamic symbol tables:
+   *   **macOS**:
+       ```bash
+       nm -gU build/cli/lib/libsqlite3.dylib
+       ```
+   *   **Linux**:
+       ```bash
+       nm -D build/cli/lib/libsqlite3.so
+       ```
+   *   **Windows** (using MSVC Developer Command Prompt):
+       ```cmd
+       dumpbin /EXPORTS build\cli\lib\sqlite3.dll
+       ```
+4. **Confirm Target Exports**: Verify that the command outputs **only** the explicitly kept entry point functions (e.g. `sqlite3_libversion`) and does not output any unreferenced/stripped symbols.
+5. **No Bundle Scenario**: If the application does not import or invoke any methods from the native library:
+   - Verify that the link hook logs: `Skipping linking as no symbols are to be kept.`
+   - Verify that no library was built/placed in the production bundle (the `.dylib`/`.so`/`.dll` file is not generated, saving bundle size).
+
+### 4. Verify Offline Compliance (User Defines)
+Confirm offline compliance is fully active and the download fallback executes perfectly offline:
+
+1. Configure the `local_build: true` define for your package in the package's `pubspec.yaml` (or the workspace root `pubspec.yaml`):
+   ```yaml
+   hooks:
+     user_defines:
+       <your_package_name>:
+         local_build: true
+   ```
+2. Disable the machine's network adapter or run in a sandboxed offline shell.
+3. Launch unit tests:
+   ```bash
+   dart test
+   ```
+4. Verify the test suite successfully compiles local source files using host compilers, has no compile errors, and never attempts network download requests.