dami 1.0.0

data/docs/11.Localization.md

@@ -0,0 +1,435 @@
+# Chapter 11: Internationalization (I18n) & Localization
+
+Building a world-class application means speaking your users' language. Internationalization (i18n) is often a complex afterthought, involving scattered files and inconsistent APIs. Dami treats it as a first-class citizen with a simple, powerful philosophy: **all user-facing text that the framework is aware of should live in one clean, consistent, and localizable place.**
+
+This is achieved through a new, core DSL: `Dami.localize`.
+
+
+
+This unified system is not just for validation messages. It's a complete solution for translating every piece of "chrome" text connected to your data layer, providing a single source of truth for your application's vocabulary.
+
+---
+
+## The `Dami.localize` DSL
+
+The `Dami.localize` block is the central hub for all framework-aware translations. You define a scope (like `:validations` or `:models`), specify a language, and provide your translations using a clean, block-based syntax.
+
+```ruby
+# config/locales/dami.rb
+
+Dami.localize :validations do
+  en do
+    set :required, "cannot be blank"
+    set :min_length, ->(min) { "is too short (minimum: #{min} characters)" }
+  end
+
+  es do
+    set :required, "no puede estar en blanco"
+    set :min_length, ->(min) { "es demasiado corto (mínimo: #{min} caracteres)" }
+  end
+end
+````
+
+This approach is powerful because it's pure Ruby. You can load these definitions from anywhere, and it's completely explicit—no "magic" `method_missing`.
+
+-----
+
+## Why `Dami.localize` is More Than Just Validations
+
+Your ORM is the single source of truth for your data's structure. As such, it's the perfect place to manage the human-readable text associated with that structure. `Dami.localize` is designed to be a holistic system, covering four key scopes.
+
+### 1\. `:validations` - Error Messages
+
+This is the most common use case. It allows you to provide clean, translated error messages for all of Dami's built-in and custom validation rules.
+
+  * **The Problem:** Hardcoded English error messages scattered throughout your models or initializers.
+  * **The Solution:** A central `validations` scope that the `Dami.behavior` block will automatically use.
+
+<!-- end list -->
+
+```ruby
+Dami.localize :validations do
+  en { set :email, "must be a valid email address" }
+  es { set :email, "debe ser una dirección de correo electrónico válida" }
+end
+```
+
+### 2\. `:models` - Attribute & Model Names
+
+  * **The Problem:** Your database uses `first_name`, but your HTML form label should say "First name". This couples your views to your schema's raw column names.
+  * **The Solution:** A `models` scope to provide canonical, human-readable names for your models and their attributes.
+
+<!-- end list -->
+
+```ruby
+Dami.localize :models do
+  en do
+    attributes_for :users do
+      set :model_name, "User"
+      set :first_name, "First Name"
+    end
+  end
+  es do
+    attributes_for :users do
+      set :model_name, "Usuario"
+      set :first_name, "Nombre"
+    end
+  end
+end
+
+# A future helper would make this easy to use in views:
+# Dami.human_attribute_name(:users, :first_name, locale: :es) # => "Nombre"
+```
+
+### 3\. `:enums` - Stored Values
+
+  * **The Problem:** Your database stores a post's status as `"published"`, but you want to display "Published" or "Publicado" to the user.
+  * **The Solution:** An `enums` scope to map raw data values to clean, display-friendly text.
+
+<!-- end list -->
+
+```ruby
+Dami.localize :enums do
+  en do
+    enum_for :posts, :status do
+      set :published, "Published"
+      set :draft, "In Draft"
+    end
+  end
+end
+```
+
+### 4\. `:errors` - System Exceptions
+
+  * **The Problem:** Dami might raise a `Dami::ProtectionError`. You want to rescue this and show a friendly, translated message to the user.
+  * **The Solution:** An `errors` scope to provide user-facing translations for framework-level exceptions.
+
+<!-- end list -->
+
+```ruby
+Dami.localize :errors do
+  en { set :protection_error, "You are not authorized to change one or more of the submitted fields." }
+end
+```
+
+-----
+
+## Locale Management
+
+Dami is designed to integrate seamlessly with the existing Ruby ecosystem. It uses a smart, three-tiered approach to determine the current language.
+
+1.  **Manual Override:** You can force a process-wide default with `Dami.locale = :es` (set it once at boot). Inside a web request use `Dami.thread_locale = :es` or `Dami.with_locale` instead — those are thread-local, so one request's locale never leaks into another thread's.
+2.  **Automatic `I18n` Detection:** If the standard `i18n` gem is loaded, Dami will **automatically** use `I18n.locale`. This means it works out-of-the-box with Rails, Sinatra, and most other Ruby web frameworks.
+3.  **Default:** If neither of the above is present, it defaults to `:en`.
+
+For testing or handling specific requests, you can use the `Dami.with_locale` helper, which guarantees the original locale is restored. It is thread-local: only the calling thread sees the temporary locale.
+
+```ruby
+Dami.with_locale(:es) do
+  # All Dami operations inside this block will use the Spanish locale.
+  puts Dami.current_locale # => :es
+end
+puts Dami.current_locale # => :en (back to the original)
+```
+---
+
+## Helper Methods for Views and Forms
+
+Dami provides convenient helper methods to retrieve human-readable labels for your models and fields. These are essential for building forms, table headers, and any UI that displays field names to users.
+
+### `Dami.localize_field` (alias: `lf`)
+
+Retrieves the translated label for a specific field on a model.
+```ruby
+# Define your translations
+Dami.localize :models do
+  en do
+    attributes_for :users do
+      set :first_name, "First Name"
+      set :email, "Email Address"
+      set :phone_number, "Phone"
+    end
+  end
+  es do
+    attributes_for :users do
+      set :first_name, "Nombre"
+      set :email, "Correo Electrónico"
+      set :phone_number, "Teléfono"
+    end
+  end
+end
+
+# In your views or controllers
+Dami.localize_field(:users, :first_name)  # => "First Name" (or "Nombre" if locale is :es)
+Dami.lf(:users, :email)                   # => "Email Address" (shorthand)
+```
+
+**Real-world example in a form:**
+```ruby
+# In a Sinatra/Hanami view
+<form>
+  <label><%= Dami.lf(:users, :first_name) %>:</label>
+  <input type="text" name="user[first_name]">
+  
+  <label><%= Dami.lf(:users, :email) %>:</label>
+  <input type="email" name="user[email]">
+</form>
+```
+
+When a Spanish-speaking user visits, the labels automatically display as "Nombre" and "Correo Electrónico".
+
+
+### `Dami.localize_model` (alias: `lm`)
+
+Retrieves the translated name for a model itself. Useful for page titles, breadcrumbs, and headers.
+```ruby
+Dami.localize :models do
+  en do
+    attributes_for :users do
+      set :model_name, "User"
+    end
+    attributes_for :products do
+      set :model_name, "Product"
+    end
+  end
+  es do
+    attributes_for :users do
+      set :model_name, "Usuario"
+    end
+    attributes_for :products do
+      set :model_name, "Producto"
+    end
+  end
+end
+
+# In your views
+Dami.localize_model(:users)  # => "User" (or "Usuario" if locale is :es)
+Dami.lm(:products)           # => "Product" (shorthand)
+```
+
+**Real-world example in a page header:**
+```ruby
+# In a controller
+class UsersController
+  def index
+    @model_name = Dami.lm(:users)
+    # Renders "Users" or "Usuarios" depending on locale
+  end
+end
+
+# In the view
+<h1><%= @model_name %> Directory</h1>
+```
+
+
+### Explicit Locale Override
+
+Both helpers accept an optional `locale:` parameter to override the current locale:
+```ruby
+Dami.locale = :en
+
+# Force Spanish translation
+Dami.lf(:users, :first_name, locale: :es)  # => "Nombre"
+Dami.lm(:users, locale: :es)               # => "Usuario"
+
+# Current locale still English
+Dami.lf(:users, :first_name)  # => "First Name"
+```
+
+This is useful for:
+- Admin interfaces showing translations for review
+- Email templates that need to use the recipient's preferred language
+- Testing different locale outputs
+
+### Automatic Locale Detection
+
+The helpers automatically use the current locale through the three-tier detection system:
+
+1. **Manual override**: `Dami.locale = :es`
+2. **I18n gem**: `I18n.locale` (automatic in Rails/Sinatra)
+3. **Default**: `:en`
+
+**In a Rails controller:**
+```ruby
+class ProductsController < ApplicationController
+  def show
+    # Rails sets I18n.locale per-request based on user preference
+    # Dami automatically picks it up
+    
+    @product_name_label = Dami.lf(:products, :name)
+    # => "Product Name" for English users
+    # => "Nombre del Producto" for Spanish users
+    # Zero configuration needed!
+  end
+end
+```
+
+### Building Dynamic Forms
+
+Here's a complete example of using these helpers to build a multi-lingual form:
+```ruby
+# Define all your translations
+Dami.localize :models do
+  en do
+    attributes_for :products do
+      set :model_name, "Product"
+      set :name, "Product Name"
+      set :description, "Description"
+      set :price, "Price"
+      set :category, "Category"
+    end
+  end
+  es do
+    attributes_for :products do
+      set :model_name, "Producto"
+      set :name, "Nombre del Producto"
+      set :description, "Descripción"
+      set :price, "Precio"
+      set :category, "Categoría"
+    end
+  end
+end
+
+# In your view template
+<h1>New <%= Dami.lm(:products) %></h1>
+
+<form action="/products" method="post">
+  <div class="field">
+    <label><%= Dami.lf(:products, :name) %></label>
+    <input type="text" name="product[name]">
+  </div>
+  
+  <div class="field">
+    <label><%= Dami.lf(:products, :description) %></label>
+    <textarea name="product[description]"></textarea>
+  </div>
+  
+  <div class="field">
+    <label><%= Dami.lf(:products, :price) %></label>
+    <input type="number" name="product[price]">
+  </div>
+  
+  <button>Create <%= Dami.lm(:products) %></button>
+</form>
+```
+
+This same template renders perfectly in any language you've defined, with zero code changes.
+
+### Best Practices
+
+1. **Define labels even for English**: Don't assume field names are self-explanatory. `email` should be "Email Address", not just "email".
+
+2. **Use shorthand in views**: `lf` and `lm` are shorter and cleaner in templates where you'll use them frequently.
+
+3. **Consistent naming**: Use the same field names across all locales to make translation maintenance easier.
+
+4. **Fallback gracefully**: If a translation is missing, the helper returns `nil`. Handle this in your views:
+```ruby
+label = Dami.lf(:users, :field_name) || "Field Name"
+```
+
+-----
+
+## Putting It All Together: An End-to-End Example
+
+This example shows how the entire system works together, from definition to execution.
+
+```ruby
+# 1. Define your translations
+Dami.localize :validations do
+  en { set :required, "cannot be blank" }
+  es { set :required, "no puede estar en blanco" }
+end
+
+# 2. Define your model and behavior
+Dami.model(:articles) { fields { field :title, :string } }
+Dami.behavior(:articles) { validate { rule :title, :required } }
+
+# 3. Trigger the validation in English (default)
+error_en = assert_raises(Dami::ValidationError) do
+  Dami.db(:articles).create(title: '')
+end
+assert_includes error_en.errors[:title], "cannot be blank"
+
+# 4. Trigger the validation in Spanish
+Dami.with_locale(:es) do
+  error_es = assert_raises(Dami::ValidationError) do
+    Dami.db(:articles).create(title: '')
+  end
+  assert_includes error_es.errors[:title], "no puede estar en blanco"
+end
+```
+
+-----
+
+## Integrating with `I18n` and Other Gems
+
+Dami's localization system is designed to be a great citizen in the Ruby ecosystem. It integrates seamlessly with standard tools like the `i18n` gem, so you don't have to choose between Dami's power and your existing workflow.
+
+### The "It Just Works" Principle: Automatic `I18n` Detection
+
+For over 90% of use cases, **you don't need to do anything.**
+
+If Dami detects that the `i18n` gem is loaded in your application (as it is in all Rails, Sinatra, and Hanami apps), it will automatically use `I18n.locale` to determine the current language. When a user's locale is set to `:es` in a web request, Dami's validation messages will automatically be in Spanish.
+
+```ruby
+# In a Rails or Sinatra controller
+I18n.with_locale(:es) do
+  begin
+    # This will now raise a ValidationError with the Spanish message
+    # because Dami automatically respects I18n.locale.
+    Dami.db(:articles).create!(title: '') 
+  rescue Dami::ValidationError => e
+    # e.errors[:title] will be ["no puede estar en blanco"]
+  end
+end
+```
+
+### Bridging the Gap: Loading YAML Files into Dami
+
+You don't need to rewrite all your existing translations. You can easily load standard `i18n` YAML files directly into Dami's localization system in an initializer. This gives you a single source of truth for all your application's text.
+
+Imagine you have a standard Rails `es.yml` file:
+
+```yaml
+# config/locales/es.yml
+es:
+  dami:
+    validations:
+      required: "no puede estar en blanco (desde YAML)"
+    models:
+      user:
+        first_name: "Nombre (desde YAML)"
+```
+
+You can load this into Dami in a single, clean step:
+
+```ruby
+# config/initializers/dami_i18n.rb
+require 'yaml'
+
+# Load the YAML file
+translations = YAML.load_file('config/locales/es.yml')
+dami_translations = translations['es']['dami']
+
+# Feed the translations into Dami's DSL
+Dami.localize :validations do
+  es do
+    dami_translations['validations'].each do |key, value|
+      set key.to_sym, value
+    end
+  end
+end
+
+Dami.localize :models do
+  es do
+    attributes_for :user do
+      dami_translations['models']['user'].each do |key, value|
+        set key.to_sym, value
+      end
+    end
+  end
+end
+```
+
+This pattern allows you to maintain your translations in the standard `i18n` format while still benefiting from Dami's fast, type-safe localization engine at runtime. It's the best of both worlds.

data/docs/12.TheDamiWay.md

@@ -0,0 +1,227 @@
+Absolutely. This is the perfect way to end the documentation—a confident, opinionated "manifesto" that clearly articulates Dami's superior design philosophy. Your draft is a great start, and we can definitely crank up the energy to get developers hyped.
+
+You're right, the draft is missing the knockout punches about validations and other key differentiators. Let's upgrade this from a simple comparison to a powerful final statement.
+
+Here is the revised, high-energy final chapter.
+
+-----
+
+````markdown
+# Chapter 12: The Dami Way - A Manifesto
+
+You've learned the "what" of Dami's features. This final chapter is about the "why." It's a declaration of the principles that make Dami a fundamentally better way to build modern, maintainable applications.
+
+Dami was not created to be another clone in a sea of ORMs. It was forged from experience, designed to eliminate the common pain points and architectural decay that plague traditional frameworks. This philosophy is **"The Dami Way,"** and it's built on four pillars: **Clarity, Architectural Purity, Performance, and Ergonomic Joy.**
+
+This chapter is a "shootout" that compares Dami's design choices to the conventional approach (represented by Rails/ActiveRecord). By the end, it will be blatantly obvious why Dami is a superior choice.
+
+
+
+---
+
+## 1. Architectural Purity: The Decisive End of the "Fat Model"
+
+The single biggest source of technical debt in most web applications is the "fat model"—a single file that becomes a sprawling, thousand-line dumping ground for schema, business logic, query logic, and presentation helpers. It's impossible to read, a nightmare to test, and actively resists change.
+
+#### **The Old Way: The Monolithic Model**
+
+In a typical Rails application, every concern is crammed into a single `ApplicationRecord` class. This convenience comes at a devastating long-term cost.
+
+```ruby
+# The "Fat Model" Anti-Pattern in Rails
+class User < ApplicationRecord
+  # --- Structure, Behavior, Querying, and Presentation are all mixed ---
+  has_many :posts
+  
+  validates :email, presence: true, uniqueness: true
+  before_save :downcase_email # A callback... but where is it defined?
+
+  scope :active, -> { where(status: 'active') }
+
+  def full_name
+    "#{first_name} #{last_name}"
+  end
+  # ... 500 more lines of tangled logic ...
+end
+````
+
+#### **The Dami Way: The Four Pillars of Clarity**
+
+Dami makes this architectural mess impossible **by design**. It provides four distinct, purpose-built DSLs. This isn't a suggestion; it's a core feature enforced by the framework itself.
+
+```ruby
+# The Dami Way: Clean, Enforced Separation of Concerns
+
+# --- 1. Structure (The Skeleton) ---
+Dami.model(:users) { fields { ... }; relationships { ... } }
+
+# --- 2. Behavior (The Internal Rules) ---
+Dami.behavior(:users) { validate { ... }; before(:save) { ... } }
+
+# --- 3. Presentation (The Public Interface) ---
+Dami.present(:users) { def full_name; ...; end }
+
+# --- 4. Querying (The Collection Logic) ---
+Dami.scopes(:users) { scope :active, -> { ... } }
+```
+
+### **The Shootout: Why Dami Wins Decisively**
+
+  * **Clarity & Discoverability:** When you open a Dami model file, the architecture is immediately obvious. You know exactly where to find schema, write-side rules, read-side helpers, and query logic. No more hunting for a `scope` buried between a dozen private methods.
+  * **Superior Testability:** Each pillar can be tested in isolation. You can unit test your presenter methods with plain Ruby hashes, without ever touching the database. You can test your behavior rules without mocking query scopes. This leads to faster, more reliable, and more focused tests.
+  * **Architectural Guardrails:** Dami actively prevents architectural decay. You *can't* put a validation rule in your `model` block. The framework will stop you. These guardrails ensure the codebase stays clean and understandable as it grows and new developers join the team.
+
+-----
+
+## 2\. Validations: A Central Registry vs. Ad-Hoc Chaos
+
+Validations are critical, but in most frameworks, they are a source of constant repetition and inconsistency.
+
+#### **The Old Way: Repetitive, Scattered Definitions**
+
+In Rails, if you need a custom `phone_number` validation, you have to define it ad-hoc in every single model that needs it, often with slightly different regexes and error messages.
+
+```ruby
+# The Repetitive Anti-Pattern in Rails
+class User < ApplicationRecord
+  validates :phone, format: { with: /\A\d{10}\z/, message: "must be 10 digits" }
+end
+
+class Company < ApplicationRecord
+  validates :main_phone, format: { with: /\A\d{3}-\d{3}-\d{4}\z/, message: "use XXX-XXX-XXXX format" }
+end # ❌ Inconsistent logic and messages!
+```
+
+#### **The Dami Way: The Central Validation Registry**
+
+Dami treats validations as a first-class, reusable component of your application. You define a rule **once** in a central registry and reuse it everywhere.
+
+```ruby
+# The Dami Way: Define Once, Reuse Everywhere
+
+# 1. Register your custom rule
+Dami.rules :default, {
+  phone: { 
+    check: ->(v) { v.to_s.gsub(/\D/, '').length == 10 }, 
+    message: "must be a valid 10-digit phone number" 
+  }
+}
+
+# 2. Use it by its simple, declarative name
+Dami.behavior(:users) { validate { rule :phone, :phone } }
+Dami.behavior(:companies) { validate { rule :main_phone, :phone } } # ✅ Consistent logic and message!
+```
+
+### **The Shootout: Why Dami Wins Decisively**
+
+  * **DRY (Don't Repeat Yourself):** Dami's registry eliminates the possibility of having dozens of slightly different, copy-pasted validations littered across your codebase.
+  * **Consistency:** It guarantees that the logic and error message for a given rule are identical everywhere, providing a consistent user experience.
+  * **Maintainability:** If your business rule for a "phone number" changes, you update it in **one single place**, and the entire application is instantly updated. This is a massive win for long-term maintenance.
+
+-----
+
+## 3\. Business Logic: Explicit Orchestration vs. "Callback Hell"
+
+Complex business processes are the heart of any application. Dami provides a dedicated, top-tier tool for this, while other frameworks rely on a pattern that is notoriously brittle and opaque.
+
+#### **The Old Way: Implicit Callback Chains ("Callback Hell")**
+
+A user signup process in Rails often becomes an invisible, untestable chain of `after_create` callbacks. When it breaks, it's nearly impossible to debug.
+
+```ruby
+# The "Callback Hell" Anti-Pattern
+class User < ApplicationRecord
+  after_create :send_welcome_email, :sync_to_crm, :assign_to_default_team
+end
+
+# In the controller:
+def create
+  @user = User.new(user_params)
+  if @user.save # ❌ What happens here? An invisible, multi-step process kicks off.
+    # What if sync_to_crm fails? The user is already created,
+    # the email is sent, but the system is now in an inconsistent state.
+  end
+end
+```
+
+#### **The Dami Way: An Explicit, Transactional Flow**
+
+Dami's **Flows** make the entire business process visible, atomic, and safe. It reads like a clear, imperative script for your most critical workflows.
+
+```ruby
+# The Dami Way: An Explicit, Readable, and Resilient Script
+Dami.run(:user_signup_flow) do
+  # 1. Validate and prepare all incoming data
+  clean_data = prepare CreateUserCommand, with: params
+
+  # 2. Run all database operations inside a single, atomic transaction
+  user = db(:users).create(clean_data[:user])
+  db(:teams).default.add_member(user)
+
+  # 3. Perform external actions with built-in resilience
+  perform "Sync to CRM", retry_options: { on: [Crm::ApiError], times: 2 } do
+    CrmService.sync_user(user)
+  end
+
+  # 4. Safely enqueue side effects ONLY AFTER the transaction commits
+  succeed with: user, and_then: [
+    WelcomeEmailJob.with(user_id: user[:id])
+  ]
+end
+```
+
+### **The Shootout: Why Dami Wins Decisively**
+
+  * **Visibility & Clarity:** The Dami Flow is a self-documenting script. Any developer can read it top-to-bottom and understand the entire business process. There are no hidden actions.
+  * **Transactional Integrity:** If the `CrmService` call fails, the entire database transaction is **automatically rolled back**. The user and team membership are never saved. The system remains in a consistent state, eliminating an entire class of bugs.
+  * **Safety for Side Effects:** The `and_then:` block is a transaction-aware gatekeeper. It guarantees that irreversible actions like sending an email or charging a credit card happen **only after** all database operations have been successfully and permanently committed. This solves the infamous "welcome email sent to a ghost user" bug.
+
+-----
+
+### A Caveat: When *Not* to Use Dami (The Honest Guide)
+
+Every great tool is defined as much by what it *doesn't* do as by what it does. Dami is an opinionated framework designed for a specific philosophy. We believe it's a better way to build, but like any sharp tool, it's not the right one for every single job.
+
+Being open about these trade-offs is critical. Dami might **not** be the best fit for your project if:
+
+#### 1. ...You Need a Massive, Established Ecosystem Out of the Box.
+
+The Rails and ActiveRecord ecosystem is a vast, mature jungle of gems and plugins for everything from authentication (`Devise`) to admin panels (`ActiveAdmin`). This is an incredible strength born of over a decade of community effort.
+
+**Dami does not have this.**
+
+* **The Dami Trade-off:** Dami prioritizes architectural purity and performance over a vast, plug-and-play ecosystem. It provides a cleaner, more robust foundation for you to build your *own* solutions, free from the constraints and magic of a monolithic framework.
+* **The Bottom Line:** If your project's success depends on quickly integrating a dozen mature, third-party gems for common features, the ActiveRecord ecosystem is currently the more pragmatic choice.
+
+#### 2. ...You Need Broad Database Support *Today*.
+
+Dami v1.0 is laser-focused on providing a world-class, battle-tested experience for a single database: **SQLite**. This focus allows us to guarantee performance and stability.
+
+* **The Dami Trade-off:** We chose to do one thing exceptionally well before expanding. Support for **PostgreSQL** and **MySQL** are high-priority items on the roadmap for the v1.x series, but they are not here today.
+* **The Bottom Line:** If your production environment requires PostgreSQL, MySQL, or another database *right now*, you should wait for a future release of Dami.
+
+#### 3. ...Your Team is 100% "Rails Fluent" and on a Tight Deadline.
+
+Dami's "Four Pillars" architecture is its greatest strength, but it represents a different paradigm. It requires un-learning the "fat model" habit and embracing an explicit separation of concerns.
+
+* **The Dami Trade-off:** Dami offers a long-term solution to the pain points of architectural decay, but this requires an initial investment in learning a new, more disciplined way of organizing code. This shift, while powerful, requires team buy-in.
+* **The Bottom Line:** If your team is under a tight deadline and is composed entirely of senior Rails developers who can move at lightning speed within that ecosystem, the cost of switching paradigms might outweigh the immediate benefits.
+
+#### 4. ...You Want an All-in-One, "Convention over Configuration" Framework.
+
+Dami is a world-class **ORM and business logic layer**. It is not a full-stack web framework. It has no opinions about routing, controllers, views, or asset pipelines.
+
+* **The Dami Position:** This is a feature, not a limitation. Dami is designed to be the powerful data and logic core of *any* Ruby application—a Sinatra or Hanami web app, a command-line tool, a data processing script, or a standalone API. It doesn't lock you into a single way of building.
+* **The Bottom Line:** If you want a single command to generate a full CRUD application from front to back, you are looking for a full-stack framework like Rails, not a specialized, best-in-class component like Dami.
+
+---
+
+## Your Call to Action
+
+The Dami Way is a commitment to building better software. It's a choice to favor clarity over magic, purity over convenience, and long-term maintainability over short-term shortcuts.
+
+You've seen the difference. You've seen the architecture. Now it's time to decide if you're ready to build on a foundation designed for the long haul.
+
+Dami is not a Swiss Army knife. **It's a scalpel. And for the right job, it's the best tool there is.**
+
+**Get hyped. Get building.** Welcome to The Dami Way.