Pentaho already compiled.
Now compile it into dbt.

No new extraction. Just a second rendering of what's already compiled.

$ ekos dbt generate
dbt models generated.
  Models rendered: 98
  Source tables: 23
  Output: dbt-generated

A real TableInput step becomes a real dbt source.

<step>
  <name>Sales Person</name>
  <type>TableInput</type>
  <connection>AdventureWorks</connection>
  <sql>SELECT
  BusinessEntityID
, TerritoryID
FROM Sales.SalesPerson
</sql>

select
    BusinessEntityID,
    TerritoryID
from {{ source('pentaho', 'Sales.SalesPerson') }}

The FROM clause resolves into a real dbt source() reference, and the real declared columns — read from the step's structured <row-meta>/<value-meta>/<name> metadata, not parsed out of the free-text SQL — become a real explicit column list instead of select *.

StreamLookup and MergeJoin have their own key XML shapes. Now both are read correctly.

<step>
  <name>Sales Territory Lookup</name>
  <type>StreamLookup</type>
  <lookup>
    <key>
      <name>TerritoryID</name>
      <field>territory_id</field>
    </key>
  </lookup>

-- NOTE: l/r assignment is positional...
select *
from {{ ref('fact_sales_ktr_0') }} as l
left join {{ ref('fact_sales_ktr_14') }} as r
    on territory_id = TerritoryID -- TODO: verify column
       qualification, source dialect: Pentaho

Real finding from this session's Phase 2 testing, now fixed: every real MergeJoin/StreamLookup step in this repo first compiled with empty keys — each uses its own real key XML shape (<lookup><key><name>/<field> for StreamLookup; <keys_1>/<keys_2> for MergeJoin), neither matching DatabaseJoin's <keys><key><value1>/<value2> shape the analyzer originally only read. Both shapes are parsed correctly now — real keys, real join kind, real topology, for every real join in this repo.

A step EKOS can't translate still gets a real model file, still wired into the DAG.

-- Unmapped: unrecognized step type: Sequence
-- Raw source:
-- <step><name>Create surrogate key</name>
--         <type>Sequence</type>... </step>
select * from {{ ref('dim_customer_ktr_5') }} -- passthrough stub, not translated

A real Kettle Sequence (surrogate-key generator) step — no structured semantics to render, so it becomes an honest passthrough: the raw XML and reason preserved as a comment, still ref()-chained to its real upstream, so the pipeline's shape stays connected end to end even where content isn't fully translated. "Unmapped is a citizen, not a failure" — the same rule the documentation generator runs on, applied to a second output format.

Every model file resolves to a real ref(). A real schema.yml ties it together.

select * from {{ ref('dim_date_ktr_3') }}

version: 2

sources:
  - name: pentaho
    tables:
      - name: "Sales.SalesPerson"
      - name: "Sales.Customer"
      - name: "fact_sales"
      ... 20 more, real

models:
  - name: dim_customer_ktr_0
  ... 97 more, real

23 real source tables, 98 real models — every sources: entry traces to a real compiled Source node's object_name, never invented.

No expression transpiler. Filter and Calculate stay raw, flagged, not translated.

-- Filter:
select * from {{ ref(upstream) }}
where {condition} -- TODO: verify, source dialect: Pentaho

-- Calculate:
select *, {expr} as {output} -- TODO: verify, source dialect: Pentaho
from {{ ref(upstream) }}

Kettle's Filter Rows/Calculator conditions and expressions are raw, un-parsed source-dialect text — RFC 0027 already rejected building a cross-format expression AST as out of scope, since a wrong guess here would be worse than an honest TODO. Every one of these gets inlined exactly as compiled, flagged for manual verification, never silently rewritten.

Five real bugs. All from real data, none from imagination.

select
    *
from {{ source('pentaho',
  'Sales.SalesPerson') }}

-- fixed:
select
    BusinessEntityID,
    TerritoryID
from {{ source('pentaho',
  'Sales.SalesPerson') }}

All five found by running this against a real 198-object Pentaho repo, not by unit tests — the same pattern that found real bugs in the documentation generator (RFC 0035). Three live in the recovery layer (pentaho_analyzer.rs, shared with ekos docs generate), two in this feature's own rendering. Real, messy data keeps finding what hand-built fixtures miss.