tshex-cli 1.0.23 → 1.0.25

package/build/main.js

@@ -45,7 +45,7 @@ function executeCreateReactContext(templatesDir, contextDir) {
         console.error(err);
     }
 }
-function executeCreateTests(sourceDir, destinationDir, fileContents, ignoredSourceDir) {
+function executeCreateTests(sourceDir, destinationDir, fileContents, ignoredSourceDir, rootSourceDir = sourceDir) {
     const entries = fs.readdirSync(sourceDir, { withFileTypes: true });
     if (fs.existsSync(destinationDir) === false) {
         fs.mkdirSync(destinationDir, { recursive: true });
@@ -54,7 +54,7 @@ function executeCreateTests(sourceDir, destinationDir, fileContents, ignoredSour
         const sourcePath = path.join(sourceDir, entry.name);
         const destinationPath = path.join(destinationDir, entry.name);
         if (entry.isDirectory()) {
-            if (entry.name === 'shared') {
+            if (entry.name === 'shared' && sourceDir === rootSourceDir) {
                 continue;
             }
             if (ignoredSourceDir !== undefined && sourcePath.startsWith(ignoredSourceDir)) {
@@ -63,7 +63,7 @@ function executeCreateTests(sourceDir, destinationDir, fileContents, ignoredSour
             if (fs.existsSync(destinationPath) && fs.statSync(destinationPath).isDirectory() === false) {
                 continue;
             }
-            executeCreateTests(sourcePath, destinationPath, fileContents, ignoredSourceDir);
+            executeCreateTests(sourcePath, destinationPath, fileContents, ignoredSourceDir, rootSourceDir);
             continue;
         }
         if (entry.isFile() && entry.name.endsWith('.ts') && fs.existsSync(destinationPath) === false) {

package/docs/context-ports.md

@@ -1,12 +1,17 @@
 ### Context Ports
 
 Context ports define the communication available at a context boundary.
-They describe what data enters the context, what data leaves it, and which
-operation another system can invoke.
+They describe which concrete capability a context exposes, what data enters
+that capability, and what data it returns.
 
-Ports are used to keep communication contracts explicit. An adapter imports a
-port, implements that contract, and translates the external interaction into an
-application process.
+In practice a port is a specific boundary element of the system with identity:
+a command handler, a query entry point, an event consumer, a published
+endpoint, or another concrete interaction mechanism that exists because the
+running system exposes it.
+
+Types and interfaces still matter, but they are secondary. Their role is to
+make the port explicit. The main concern is the port as a real executable
+surface that another actor can call or observe.
 
 > **Hint**
 > The generated `example-ports.ts` file is only a placeholder. Replace it when
@@ -17,149 +22,105 @@ application process.
 The generated context starts with a single root file for ports.
 
 ```ts title="users/example-ports.ts"
-export function example(): void {
-    // ...
+export class ExamplePort {
+    public doSomething(): void {
+        // ...
+    }
 }
 ```
 
-This placeholder does not define a real contract yet. Its purpose is to mark
-the context root as the place where boundary-facing types and interfaces live.
+This placeholder marks the context root as the place where boundary-facing
+capabilities are declared. Replace it with the first module that defines a real
+port of the context when that capability becomes clear.
+
+Context root `.ts` files belong to this same boundary surface. Each one is
+expected to be a module that defines one or more context ports.
 
-#### First Contract
+#### First Port
 
-In the following example we replace the placeholder with a minimal contract for
+In the following example we replace the placeholder with a concrete port for
 creating a user.
 
 ```ts title="users/example-ports.ts"
-export type CreateUserRequest = {
-    user: {
-        id: string
-        email: string
-        active: boolean | null
-    }
+export interface User {
+    id: string
+    email: string
+    active: boolean | null
 }
 
-export type CreateUserResponse = {
-    user: {
-        id: string
-        email: string
-        active: boolean | null
+export class UsersRegistry {
+    public async createUser(user: User): Promise<User> {
+        // ...
     }
 }
-
-export interface CreateUserPort {
-    create(request: CreateUserRequest): Promise<CreateUserResponse>
-}
 ```
 
-`CreateUserRequest` defines the incoming payload. `CreateUserResponse` defines
-the outgoing payload. `CreateUserPort` exposes the operation available at the
-boundary.
-
-This contract says nothing about HTTP, queues, or databases. It only declares
-the shape of the communication.
-
-#### Adapter Implementation
-
-Now that the port exists, an adapter can implement it and delegate the work to
-an application service.
-
-```ts title="users/adapters/create-user.ts"
-import type {
-    CreateUserPort,
-    CreateUserRequest,
-    CreateUserResponse,
-} from '../example-ports.js'
+`User` expresses the user data that crosses the boundary. `UsersRegistry` is a
+boundary object of the context and `createUser()` is one concrete capability
+that it exposes.
 
-type CreateUserService = {
-    execute(data: {
-        id: string
-        email: string
-        active: boolean | null
-    }): Promise<CreateUserResponse>
-}
-
-export class CreateUserAdapter implements CreateUserPort {
-    public constructor(
-        private readonly service: CreateUserService,
-    ) {}
-
-    public async create(
-        request: CreateUserRequest,
-    ): Promise<CreateUserResponse> {
-        return this.service.execute({
-            id: request.user.id,
-            email: request.user.email,
-            active: request.user.active,
-        })
-    }
-}
-```
+This definition focuses on the interaction the context makes available. The
+port keeps its identity as one boundary capability while making its data and
+action explicit.
 
-The adapter implements `CreateUserPort`, so it must provide `create()`. Inside
-that method it translates the root-level request into the input expected by the
-application service.
+The port is the executable object that this context exposes. Types help
+describe it and make its boundary explicit.
 
-This is the normal flow of the generated structure:
+This is the normal flow inside the context boundary:
 
-```text
-external system -> adapter -> application -> domain
+```mermaid
+flowchart LR
+    caller["Caller"] --> port[Concrete port]
+    port --> application[Application]
+    application --> domain[Domain]
 ```
 
-The port belongs to the boundary. The adapter materializes the boundary. The
-application process executes the use case.
+The port belongs to the boundary because it is part of what the context
+exposes. The application process executes the use case behind the exposed
+capability and uses domain capabilities.
 
 #### Multiple Port Files
 
-As the context grows, you can keep several contracts at the context root.
+As the context grows, you can keep several port modules at the context root.
 
-```ts title="users/list-users.ts"
-export type ListUsersRequest = {
-    active: boolean | null
-}
-
-export type ListUsersResponse = {
-    users: Array<{
-        id: string
-        email: string
-        active: boolean | null
-    }>
-}
-
-export interface ListUsersPort {
-    list(request: ListUsersRequest): Promise<ListUsersResponse>
+```ts title="users/registry.ts"
+export class UsersRegistry {
+    public async listUsers(): Promise<User[]> {
+        // ...
+    }
 }
 ```
 
-An adapter can then import the contract from the file that owns it.
+Another caller can then import the port from the file that owns it.
 
-This arrangement is useful when one context exposes several independent forms
-of communication. A single file works well for a small context. Separate files
-become easier to maintain when responsibilities start to diverge.
+This arrangement is useful when one context exposes several independent
+capabilities. A single file works well for a small context. Separate files
+become easier to maintain when each port has its own identity and
+responsibility.
 
 > **Warning**
-> A port should define communication, not domain behavior. Avoid moving entity
-> rules, repository logic, or infrastructure details into the port file.
+> A port should define an exposed boundary capability.
+> Keep business rules, repository logic, and infrastructure details in their
+> corresponding layers.
 
 #### Example Layout
 
 The following structure keeps ports at the root while the implementation lives
 in the generated folders.
 
-```text
-users/
-├── example-ports.ts
-├── list-users.ts
-├── adapters/
-├── application/
-└── domain/
+```mermaid
+flowchart TD
+    users["users/"] --> registry["registry.ts"]
+    users --> application["application/"]
+    users --> domain["domain/"]
 ```
 
 This layout keeps the context boundary visible from the top level. It also
-reduces coupling between adapters because they all import the same contracts.
+makes each exposed capability easy to locate because the port modules stay at
+the root of the context.
 
 #### Next Step
 
-After defining a port, implement the corresponding adapter and connect it to an
-application service. The surrounding structure is described in
-`library-structure.md`.
+After defining a port, implement the corresponding executable path and connect
+it to an application service. The surrounding structure is described in
+`library-structure.md`.

package/docs/generated-file-reference.md

@@ -61,14 +61,14 @@ application coordinates data access without forcing a specific driver.
 
 #### Context Files
 
-Each generated context starts with a root port file and three directories.
+Each generated context starts with an example port file and three directories.
 
 | Path | Responsibility |
 | --- | --- |
-| `users/example-ports.ts` | Placeholder root file for context ports. |
+| `users/example-ports.ts` | Example module for context ports. All context root `.ts` files are expected to define context ports. |
 | `users/domain/` | Domain capabilities and rules for the context. |
 | `users/application/` | Processes that use domain capabilities to fulfill system purposes. |
-| `users/adapters/` | Integrations that implement ports and connect the context to external systems. |
+| `users/adapters/` | Integrations that wraps third-party libraries or context ports. |
 
 The `users/` path is an example context name. Your project can generate one or
 more contexts with the same internal layout.
@@ -81,8 +81,8 @@ Use the following sequence when deciding where new code belongs.
 2. Put reusable application contracts in `shared/application`.
 3. Put context-specific rules in `<context>/domain`.
 4. Put use cases in `<context>/application`.
-5. Put boundary implementations in `<context>/adapters`.
-6. Put boundary contracts at the context root.
+5. Put transport and infrastructure integrations in `<context>/adapters`.
+6. Put concrete boundary ports in context root `.ts` files.
 
 This reference explains placement. The architectural rationale is described in
-`library-structure.md`.
+`library-structure.md`.

package/docs/library-structure.md

@@ -13,11 +13,12 @@ language, rules, and operations.
 
 The root contains the entry points of the generated library.
 
-```text
-index.d.ts
-main.ts
-shared/
-users/
+```mermaid
+flowchart TD
+    root["Library root"] --> index["index.d.ts"]
+    root --> main["main.ts"]
+    root --> shared["shared/"]
+    root --> users["users/"]
 ```
 
 `index.d.ts` defines root-level types. `main.ts` starts as a placeholder for
@@ -29,10 +30,10 @@ or more context directories.
 The `shared` directory contains concepts that can be reused by multiple
 contexts.
 
-```text
-shared/
-├── application/
-└── domain/
+```mermaid
+flowchart TD
+    shared["shared/"] --> application["application/"]
+    shared --> domain["domain/"]
 ```
 
 `shared/domain` contains modeling foundations such as value objects, entities,
@@ -47,11 +48,12 @@ Until then, keep it close to the context that owns the rule.
 A context groups the vocabulary, rules, and operations of one application
 capability.
 
-```text
-users/
-billing/
-inventory/
-sales/
+```mermaid
+flowchart TD
+    contexts["Contexts"] --> users["users/"]
+    contexts --> billing["billing/"]
+    contexts --> inventory["inventory/"]
+    contexts --> sales["sales/"]
 ```
 
 Each context can evolve independently while still reusing the abstractions from
@@ -62,17 +64,22 @@ the system.
 
 Every generated context starts with the same internal structure.
 
-```text
-users/
-├── example-ports.ts
-├── adapters/
-├── application/
-└── domain/
+```mermaid
+flowchart TD
+    users["users/"] --> ports["example-ports.ts"]
+    users --> adapters["adapters/"]
+    users --> application["application/"]
+    users --> domain["domain/"]
 ```
 
-`example-ports.ts` is the root communication surface of the context.
+`example-ports.ts` is an example module in the root communication surface of
+the context.
 `domain/` contains capabilities and rules. `application/` contains processes.
-`adapters/` contains boundary implementations.
+`adapters/` contains integrations that wrap third-party libraries or context
+ports.
+
+Context root `.ts` files belong to the boundary surface of the context. Each
+one is expected to be a module that defines one or more context ports.
 
 #### Domain
 
@@ -103,34 +110,40 @@ business rules themselves.
 The adapters layer contains the integrations that connect a context to other
 systems.
 
-An adapter can expose an HTTP handler, consume a message, call a remote API,
-implement a data driver, or connect to an event bus. Its role is to translate
-external input or output into the contracts expected by the application layer.
+An adapter wraps a third-party library or a context port so that the context
+can interact with a concrete transport or infrastructure path. An adapter can
+expose an HTTP handler, consume a message, call a remote API, implement a data
+driver, or connect to an event bus.
 
 #### Ports
 
 Ports define the communication available at the context boundary.
 
 They live at the context root because they describe how the context is used
-from the outside. An adapter imports a port, implements it, and delegates the
-work to an application process.
+from the outside. A port is the concrete object the context exposes. Adapters
+or other callers can use that port object and route work into an application
+process.
 
-The generated template starts with `example-ports.ts`, but a larger context may
-split ports across several files. The detailed guidance for that layout lives in
-`context-ports.md`.
+The generated template starts with `example-ports.ts`. As the context grows,
+additional context root `.ts` modules can define more ports. The detailed
+guidance for that layout lives in `context-ports.md`.
 
 #### Dependency Direction
 
 The normal dependency direction is the following:
 
-```text
-adapter -> port
-adapter -> application
-application -> domain
+```mermaid
+flowchart LR
+    adapter[Adapter] --> thirdParty["Third-party library"]
+    adapter --> port[Port]
+    port --> application[Application]
+    application --> domain
 ```
 
 This direction keeps the core model isolated from transport and infrastructure
-details. The deeper a layer is, the less it should know about the outside.
+details. Adapters integrate with external libraries and context ports. Ports
+connect the context boundary to application processes. The deeper a layer is,
+the less it should know about the outside.
 
 > **Warning**
 > Avoid importing adapter-specific concerns into the domain layer. Once a domain
@@ -141,23 +154,23 @@ details. The deeper a layer is, the less it should know about the outside.
 
 The following diagram shows the runtime flow of a typical operation.
 
-```text
-External system
-      |
-      v
-Port + adapter
-      |
-      v
-Application service
-      |
-      v
-Domain capability
+```mermaid
+flowchart TD
+    main["main.ts"] --> system["Own system"]
+    system --> application["Application services"]
+    application --> domain["Domain capabilities"]
+    system --> adapter[Adapters]
+    adapter --> port[Port]
+    adapter --> thirdParty["Third-party libraries"]
+    thirdParty --> external["External systems"]
 ```
 
-The adapter receives the input, the application service coordinates the use
-case, and the domain provides the rules and behavior required by that use case.
+`main.ts` is the runtime entry point into the own system. Inside that system,
+application services use domain capabilities, while adapters can depend on
+ports and third-party libraries. The port branch stops at the boundary because
+what exists beyond that port depends on the system that implements it.
 
 #### Next Step
 
 Use this structure as the default layout for new code. When you need to inspect
-the purpose of a generated file, consult `generated-file-reference.md`.
+the purpose of a generated file, consult `generated-file-reference.md`.

package/docs/shared/application/data.md

@@ -176,10 +176,15 @@ and the representation used by the context.
 
 The normal flow of the data abstractions is the following:
 
-```text
-service -> repository -> driver -> data manager -> raw records
-service <- repository <- transformed records
+```mermaid
+flowchart LR
+    service[Service] --> repository[Repository]
+    repository --> driver[Driver]
+    driver --> manager["Data manager"]
+    manager --> raw["Raw records"]
+    repository --> transformed["Transformed records"]
+    transformed --> service
 ```
 
 This separation keeps the application service focused on orchestration while
-the repository focuses on transformation.
+the repository focuses on transformation.

package/docs/shared/application/events.md

@@ -135,10 +135,12 @@ registered or executed.
 
 The normal flow is the following:
 
-```text
-service -> dispatch(event)
-dispatcher -> matching handlers
-handlers -> side effects
+```mermaid
+flowchart LR
+    service[Service] --> dispatch["dispatch(event)"]
+    dispatch --> dispatcher[Dispatcher]
+    dispatcher --> handlers["Matching handlers"]
+    handlers --> effects["Side effects"]
 ```
 
-This keeps the main process separate from secondary reactions.
+This keeps the main process separate from secondary reactions.

package/docs/shared/application/http.md

@@ -123,9 +123,12 @@ cross-cutting behavior belongs in the generated HTTP abstraction.
 
 #### Example Flow
 
-```text
-request -> middleware -> handler -> response body
+```mermaid
+flowchart LR
+    request[Request] --> middleware[Middleware]
+    middleware --> handler[Handler]
+    handler --> response["Response body"]
 ```
 
 This flow keeps the transport boundary explicit while leaving framework choices
-to the adapter layer.
+to the adapter layer.

package/docs/shared/application/loggers.md

@@ -120,8 +120,11 @@ an external platform. It only depends on the application-level contract.
 
 #### Example Flow
 
-```text
-service -> Logger contract -> adapter -> logging backend
+```mermaid
+flowchart LR
+    service[Service] --> contract["Logger contract"]
+    contract --> adapter[Adapter]
+    adapter --> backend["Logging backend"]
 ```
 
-This flow keeps observability concerns outside the core process.
+This flow keeps observability concerns outside the core process.

package/docs/shared/application/services.md

@@ -112,9 +112,13 @@ result, depending on the requirements of the use case.
 
 #### Example Flow
 
-```text
-input -> service -> domain capabilities -> collaborators -> result
+```mermaid
+flowchart LR
+    input[Input] --> service[Service]
+    service --> domain["Domain capabilities"]
+    domain --> collaborators[Collaborators]
+    collaborators --> result[Result]
 ```
 
 This flow keeps orchestration in the application layer and domain meaning in
-the domain layer.
+the domain layer.

package/docs/shared/domain/aggregates.md

@@ -1,9 +1,8 @@
 ### Aggregates
 
-An aggregate is responsible for grouping multiple entities into one logical
-domain unit.
-It is used when the behavior of the concept depends on the collaboration of
-several entities instead of a single entity in isolation.
+An aggregate groups multiple entities into one logical domain unit.
+It is useful when the behavior of a concept depends on the collaboration of
+several entities working together.
 
 The generated template provides `Aggregate` as a semantic base class.
 
@@ -15,45 +14,145 @@ The generated template provides `Aggregate` as a semantic base class.
 export abstract class Aggregate {}
 ```
 
-This means the generated base class does not impose persistence rules, event
-publication, or identity behavior. Those concerns remain in the concrete domain
-model of the project.
+The class is intentionally empty. Its role is to provide the semantic base for
+an aggregate whose concrete implementation gathers the involved entities as a
+key-value structure through its own properties, such as `buyer`, `seller`,
+`order`, or `invoice`. Persistence rules, event publication, and identity
+behavior live in the concrete domain model of the project.
 
 #### First Aggregate
 
-In the following example we model a shopping cart as a group of line items.
+In the following example we model a sale as one domain unit composed of a
+buyer, a seller, an order, and an invoice generated by the aggregate itself.
 
-```ts title="users/domain/cart.ts"
+```ts title="sales/domain/sale.ts"
 import { Aggregate } from '../../shared/domain/aggregates.js'
 import { Entity } from '../../shared/domain/entities.js'
 
-class LineItem extends Entity {
+class Person extends Entity {
+	public readonly id: string
+	public readonly name: string
+
+	public constructor(id: string, name: string) {
+		super()
+		this.id = id
+		this.name = name
+	}
+
+	public equals(other: Entity): boolean {
+		return other instanceof Person && this.id === other.id
+	}
+}
+
+class Product extends Entity {
+	public readonly id: string
+	public readonly name: string
+	public readonly price: number
+
+	public constructor(id: string, name: string, price: number) {
+		super()
+		this.id = id
+		this.name = name
+		this.price = price
+	}
+
+	public equals(other: Entity): boolean {
+		return other instanceof Product && this.id === other.id
+	}
+}
+
+class Order extends Entity {
+	public readonly id: string
+	public readonly products: Product[]
+
+	public constructor(id: string, products: Product[]) {
+		super()
+		this.id = id
+		this.products = products
+	}
+
+	public equals(other: Entity): boolean {
+		return other instanceof Order && this.id === other.id
+	}
+}
+
+class Invoice extends Entity {
+	public readonly id: string
+	public readonly order: Order
+	public readonly buyer: Person
+	public readonly seller: Person
+	public readonly total: number
+
 	public constructor(
-		public readonly id: string,
-		public readonly quantity: number,
+		id: string,
+		order: Order,
+		buyer: Person,
+		seller: Person,
 	) {
 		super()
+		this.id = id
+		this.order = order
+		this.buyer = buyer
+		this.seller = seller
+		this.total = this.order.products.reduce(
+			(sum, product) => sum + product.price,
+			0,
+		)
 	}
 
 	public equals(other: Entity): boolean {
-		return other instanceof LineItem && this.id === other.id
+		return other instanceof Invoice && this.id === other.id
 	}
 }
 
-export class Cart extends Aggregate {
-	public constructor(public readonly items: Array<LineItem>) {
+export class Sale extends Aggregate {
+	public readonly buyer: Person
+	public readonly seller: Person
+	public readonly order: Order
+	protected invoice: Invoice | null
+
+	public constructor(
+		buyer: Person,
+		seller: Person,
+		order: Order,
+	) {
 		super()
+		this.buyer = buyer
+		this.seller = seller
+		this.order = order
+		this.invoice = null
+	}
+
+	public generateInvoice(): { invoice: Invoice } {
+		const id = Math.random().toString()
+		const invoice = new Invoice(
+			id,
+			this.order,
+			this.buyer,
+			this.seller,
+		)
+
+		this.invoice = invoice
+
+		return { invoice }
 	}
 
-	public totalItems(): number {
-		return this.items.reduce((sum, item) => sum + item.quantity, 0)
+	public getInvoice(): Invoice | null {
+		return this.invoice
 	}
 }
 ```
 
-`Cart` is an aggregate because its behavior depends on the collection of
-entities that compose it. `LineItem` remains an entity because its identity is
-independent inside the aggregate.
+`Sale` is an aggregate because the rule for generating the invoice depends on
+the collaboration between buyer, seller, and order. In this example, both
+buyer and seller are modeled with the same `Person` entity, while `Order`
+stores the list of purchased products and `Invoice` stores the computed
+`total`. `Invoice` is created inside the aggregate, and its constructor
+calculates the total from the order products when the invoice is generated. The
+`invoice` field stays inside the aggregate lifecycle and `getInvoice()` offers
+controlled access to the generated invoice. When a domain object already
+exists, the example uses that object directly and keeps the collaboration
+between domain parts explicit.
 
 #### Responsibility Boundary
 
@@ -66,14 +165,15 @@ Examples include:
 2. keeping related entities in a consistent state;
 3. exposing operations that depend on the collaboration of those entities.
 
-The generated `Aggregate` base class does not implement these rules for you. It
-only provides the semantic place where those rules belong.
+The generated `Aggregate` base class provides the semantic place where those
+rules belong. The concrete aggregate defines and coordinates the rules that
+keep the domain unit consistent.
 
 > **Warning**
-> Do not extend `Aggregate` only to create a container for unrelated values. Use
-> it when the concept represents one domain unit composed of several parts.
+> Extend `Aggregate` when the concept represents one domain unit composed of
+> several related parts and shared rules.
 
 #### Next Step
 
 Aggregates usually collaborate with entities and value objects. The base entity
-behavior is documented in `entities.md`.
+behavior is documented in `entities.md`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "tshex-cli",
-  "version": "1.0.23",
+  "version": "1.0.25",
   "author": "https://github.com/virtualitems/",
   "license": "MIT",
   "description": "Typescript Hexagonal Architecture CLI",
@@ -45,6 +45,7 @@
     "commander": "^12.1.0"
   },
   "devDependencies": {
+    "@fission-ai/openspec": "^1.6.0",
     "@types/node": "^22.5.4",
     "typescript": "^5.4.5"
   },

package/source/main.ts

@@ -55,7 +55,13 @@ function executeCreateReactContext(templatesDir: string, contextDir: string) {
     }
 }
 
-function executeCreateTests(sourceDir: string, destinationDir: string, fileContents: string, ignoredSourceDir?: string) {
+function executeCreateTests(
+    sourceDir: string,
+    destinationDir: string,
+    fileContents: string,
+    ignoredSourceDir?: string,
+    rootSourceDir: string = sourceDir
+) {
     const entries = fs.readdirSync(sourceDir, { withFileTypes: true })
 
     if (fs.existsSync(destinationDir) === false) {
@@ -67,7 +73,7 @@ function executeCreateTests(sourceDir: string, destinationDir: string, fileConte
         const destinationPath = path.join(destinationDir, entry.name)
 
         if (entry.isDirectory()) {
-            if (entry.name === 'shared') {
+            if (entry.name === 'shared' && sourceDir === rootSourceDir) {
                 continue
             }
 
@@ -79,7 +85,7 @@ function executeCreateTests(sourceDir: string, destinationDir: string, fileConte
                 continue
             }
 
-            executeCreateTests(sourcePath, destinationPath, fileContents, ignoredSourceDir)
+            executeCreateTests(sourcePath, destinationPath, fileContents, ignoredSourceDir, rootSourceDir)
             continue
         }