@phuc1403/musketeer 0.8.0 → 0.10.0

package/template/.claude/skills/context-map/reference/Bounded Context/realizes.md

@@ -1,9 +1,9 @@
-If your bounded context is of the type TEAM, you can specify which bounded context the team implements by using the `realizes` keyword. The following example illustrates this:
-
-```cml
-BoundedContext CustomersBackofficeTeam implements CustomerManagementDomain realizes CustomerManagementContext {
-  type = TEAM
-  domainVisionStatement = "This team is responsible for implementing ..."
-}
-```
-
+If your bounded context is of the type TEAM, you can specify which bounded context the team implements by using the `realizes` keyword. The following example illustrates this:
+
+```cml
+BoundedContext CustomersBackofficeTeam implements CustomerManagementDomain realizes CustomerManagementContext {
+  type = TEAM
+  domainVisionStatement = "This team is responsible for implementing ..."
+}
+```
+

package/template/.claude/skills/context-map/reference/Bounded Context/refines.md

@@ -1,10 +1,10 @@
-The `refines` keyword allows you to create some kind of an inheritance hierarchy in case one bounded context can be seen as a refinement of another bounded context.
-However, note that this is only a modeling information and generators do not recursively resolve the domain model (Aggregates, etc.) of refined bounded contexts.
-
-```cml
-BoundedContext ContextMapperTool refines StrategicDomainDrivenDesignContext {
-  type FEATURE
-  domainVisionStatement "Context Mapper provides a formal way to model strategic DDD Context Maps."
-  implementationTechnology "Java, Eclipse"
-}
-```
+The `refines` keyword allows you to create some kind of an inheritance hierarchy in case one bounded context can be seen as a refinement of another bounded context.
+However, note that this is only a modeling information and generators do not recursively resolve the domain model (Aggregates, etc.) of refined bounded contexts.
+
+```cml
+BoundedContext ContextMapperTool refines StrategicDomainDrivenDesignContext {
+  type FEATURE
+  domainVisionStatement "Context Mapper provides a formal way to model strategic DDD Context Maps."
+  implementationTechnology "Java, Eclipse"
+}
+```

package/template/.claude/skills/context-map/reference/Bounded Context/responsibilities.md

@@ -1,26 +1,26 @@
-With the `responsibilities` keyword you are allowed to specify the responsibilities of the bounded context, according to the DDD Responsibility Layers pattern.
-
-Can be used on [[Domain-Driven Design/Context Map/Bounded Context/Bounded Context|Bounded Context]]s and [[Aggregate]]s to specify their responsibilities.
-
-```cml
-BoundedContext CustomerManagementContext implements CustomerManagementDomain {
-  type = FEATURE
-  domainVisionStatement = "The customer management context is responsible for ..."
-  implementationTechnology = "Java, JEE Application"
-  responsibilities = "Customers", "Addresses"
-}
-
-Aggregate Customers {
-  responsibilities = "Customers", "Addresses"
-  
-  Entity Customer { 
-    aggregateRoot
-    
-    - SocialInsuranceNumber sin
-    String firstname
-    String lastname
-    - List<Address> addresses
-  }
-}
-```
-
+With the `responsibilities` keyword you are allowed to specify the responsibilities of the bounded context, according to the DDD Responsibility Layers pattern.
+
+Can be used on [[Domain-Driven Design/Context Map/Bounded Context/Bounded Context|Bounded Context]]s and [[Aggregate]]s to specify their responsibilities.
+
+```cml
+BoundedContext CustomerManagementContext implements CustomerManagementDomain {
+  type = FEATURE
+  domainVisionStatement = "The customer management context is responsible for ..."
+  implementationTechnology = "Java, JEE Application"
+  responsibilities = "Customers", "Addresses"
+}
+
+Aggregate Customers {
+  responsibilities = "Customers", "Addresses"
+  
+  Entity Customer { 
+    aggregateRoot
+    
+    - SocialInsuranceNumber sin
+    String firstname
+    String lastname
+    - List<Address> addresses
+  }
+}
+```
+

package/template/.claude/skills/context-map/reference/Bounded Context/type.md

@@ -1,23 +1,23 @@
-# Bounded Context Type
-
-The `type` provides an indicator for which reason a bounded context may have been evolved. It further allows you to specify from which viewpoint you describe your bounded contexts.
-
-- `FEATURE`: analysis or early design abstractions, taking a functional scenario view
-  - For example, everything that is related to customer management in an insurance scenario: create customer, update customer, update customer address, etc.
-- `APPLICATION`: represent more elaborated, logical designs and implementation views
-  - For example: a self-service frontend application for the customers, a backend system to manage the customers and contract, etc.
-  - An application typically encompasses multiple functional features. In a (micro-)service-oriented architecture, each (micro-)service can be seen as an application.
-- `SYSTEM`: contexts add a more physical, process- and deployment-oriented view
-  - Examples for systems: a single page application for the frontend, a Spring Boot application that realizes the domain logic, an Oracle database that holds the data, etc.
-  - An application typically consists of multiple systems.
-- `TEAM`: allows you to specify which team is implementing which bounded contexts
-  - For example: multiple teams work on different parts of the software: customer frontend team, customer backend\_ team, contracts team, etc.
-
-## Example: The "Returns" Domain
-
-1. Feature Context: We identify "Return Eligibility." This is purely a business concept: rules checking if an item is within the 30-day window and undamaged. It doesn't imply a server or a database yet.
-2. Application Context: We design the "Returns Service." This is a deployable logical unit (a Microservice) that handles eligibility, printing labels, and refund triggering. It encapsulates the "Return Eligibility" feature.
-3. System Context: When deploying, the "Returns Service" is actually split into two physical pieces:
-   - "Returns Backend API" (Spring Boot container).
-   - "Returns Dashboard" (React SPA for warehouse workers). These are two separate SYSTEM contexts.
-1. Team Context: All of the above is owned by "Team After-Sales", a squad of 6 developers.
+# Bounded Context Type
+
+The `type` provides an indicator for which reason a bounded context may have been evolved. It further allows you to specify from which viewpoint you describe your bounded contexts.
+
+- `FEATURE`: analysis or early design abstractions, taking a functional scenario view
+  - For example, everything that is related to customer management in an insurance scenario: create customer, update customer, update customer address, etc.
+- `APPLICATION`: represent more elaborated, logical designs and implementation views
+  - For example: a self-service frontend application for the customers, a backend system to manage the customers and contract, etc.
+  - An application typically encompasses multiple functional features. In a (micro-)service-oriented architecture, each (micro-)service can be seen as an application.
+- `SYSTEM`: contexts add a more physical, process- and deployment-oriented view
+  - Examples for systems: a single page application for the frontend, a Spring Boot application that realizes the domain logic, an Oracle database that holds the data, etc.
+  - An application typically consists of multiple systems.
+- `TEAM`: allows you to specify which team is implementing which bounded contexts
+  - For example: multiple teams work on different parts of the software: customer frontend team, customer backend\_ team, contracts team, etc.
+
+## Example: The "Returns" Domain
+
+1. Feature Context: We identify "Return Eligibility." This is purely a business concept: rules checking if an item is within the 30-day window and undamaged. It doesn't imply a server or a database yet.
+2. Application Context: We design the "Returns Service." This is a deployable logical unit (a Microservice) that handles eligibility, printing labels, and refund triggering. It encapsulates the "Return Eligibility" feature.
+3. System Context: When deploying, the "Returns Service" is actually split into two physical pieces:
+   - "Returns Backend API" (Spring Boot container).
+   - "Returns Dashboard" (React SPA for warehouse workers). These are two separate SYSTEM contexts.
+1. Team Context: All of the above is owned by "Team After-Sales", a squad of 6 developers.

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Anticorruption Layer.md

@@ -1,5 +1,5 @@
-```cml
-DebtCollection [D,ACL]<-[U,OHS,PL] PrintingContext {
-  implementationTechnology = "SOAP"
-}
-```
+```cml
+DebtCollection [D,ACL]<-[U,OHS,PL] PrintingContext {
+  implementationTechnology = "SOAP"
+}
+```

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Bounded Context Relationship.md

@@ -1,13 +1,13 @@
-symmetric relationships
-- [[Partnership (P)]]
-- [[Shared Kernel (SK)]]
-asymmetric relationships
-- Upstream-Downstream (generic)
-- [[Customer-Supplier (C-S)]], a special form of an Upstream-Downstream relationship
-
-```cml
-CargoBookingContext [D]<-[U] LocationContext
-
-// A colon at the end assigns a relationship a name
-LocationContext Upstream-Downstream CargoBookingContext : CargoLocationRelationship
+symmetric relationships
+- [[Partnership (P)]]
+- [[Shared Kernel (SK)]]
+asymmetric relationships
+- Upstream-Downstream (generic)
+- [[Customer-Supplier (C-S)]], a special form of an Upstream-Downstream relationship
+
+```cml
+CargoBookingContext [D]<-[U] LocationContext
+
+// A colon at the end assigns a relationship a name
+LocationContext Upstream-Downstream CargoBookingContext : CargoLocationRelationship
 ```

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Conformist.md

@@ -1,5 +1,5 @@
-```cml
-PolicyManagementContext [D,CF]<-[U,OHS,PL] CustomerManagementContext {
-  implementationTechnology = "RESTful HTTP"
-}
-```
+```cml
+PolicyManagementContext [D,CF]<-[U,OHS,PL] CustomerManagementContext {
+  implementationTechnology = "RESTful HTTP"
+}
+```

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Customer-Supplier (C-S).md

@@ -1,23 +1,23 @@
-The customer-supplier relationship is a special case of a upstream-downstream relationship
-
-A customer-supplier relationship is an upstream-downstream relationship where the downstream priorities factor into upstream planning.
-The upstream team may succeed interdependently of the fate of the downstream team and therefore the needs of the downstream have to be addressed by the upstream. They interact as customer and supplier.
-
-```cml
-CustomerSelfServiceContext [D,C]<-[U,S] CustomerManagementContext
-
-CustomerSelfServiceContext Customer-Supplier CustomerManagementContext
-
-CustomerSelfServiceContext [C]<-[S] CustomerManagementContext
-
-CustomerSelfServiceContext [D,C,ACL]<-[U,S,PL] CustomerManagementContext : Customer_Frontend_Backend_Relationship { // Relationship name is optional
-  implementationTechnology = "RESTful HTTP"
-  
-CustomerSelfServiceContext[ACL] Customer-Supplier [PL]CustomerManagementContext
-}
-```
-
-The [[Conformist]] pattern is not applicable in a Customer/Supplier relationship.
-The [[Open Host Service]] pattern is not applicable in a Customer/Supplier relationship.
-The [[Anticorruption Layer]] pattern can be used in a Customer/Supplier relationship, but this leads to contradictions with the original pattern definition according to our understanding.
+The customer-supplier relationship is a special case of a upstream-downstream relationship
+
+A customer-supplier relationship is an upstream-downstream relationship where the downstream priorities factor into upstream planning.
+The upstream team may succeed interdependently of the fate of the downstream team and therefore the needs of the downstream have to be addressed by the upstream. They interact as customer and supplier.
+
+```cml
+CustomerSelfServiceContext [D,C]<-[U,S] CustomerManagementContext
+
+CustomerSelfServiceContext Customer-Supplier CustomerManagementContext
+
+CustomerSelfServiceContext [C]<-[S] CustomerManagementContext
+
+CustomerSelfServiceContext [D,C,ACL]<-[U,S,PL] CustomerManagementContext : Customer_Frontend_Backend_Relationship { // Relationship name is optional
+  implementationTechnology = "RESTful HTTP"
+  
+CustomerSelfServiceContext[ACL] Customer-Supplier [PL]CustomerManagementContext
+}
+```
+
+The [[Conformist]] pattern is not applicable in a Customer/Supplier relationship.
+The [[Open Host Service]] pattern is not applicable in a Customer/Supplier relationship.
+The [[Anticorruption Layer]] pattern can be used in a Customer/Supplier relationship, but this leads to contradictions with the original pattern definition according to our understanding.
 The usage of Anticorruption Layer in a Customer/Supplier relationship produces a Warning only.

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Open Host Service.md

@@ -1,5 +1,5 @@
-```cml
-PrintingContext [U,OHS]->[D,ACL] PolicyManagementContext {
-  implementationTechnology = "SOAP"
-}
+```cml
+PrintingContext [U,OHS]->[D,ACL] PolicyManagementContext {
+  implementationTechnology = "SOAP"
+}
 ```

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Partnership (P).md

@@ -1,14 +1,14 @@
-```cml
-ContractsContext [P]<->[P] ClaimsContext {
-  implementationTechnology = "Messaging"
-}
-
-ContractsContext Partnership ClaimsContext {
-  implementationTechnology = "Messaging"
-}
-
-// With a colon it is possible (optionally) to add a relationship name to the specification
-ContractsContext [P]<->[P] ClaimsContext : ContractClaimRelationship {
-  implementationTechnology = "Messaging"
-}
+```cml
+ContractsContext [P]<->[P] ClaimsContext {
+  implementationTechnology = "Messaging"
+}
+
+ContractsContext Partnership ClaimsContext {
+  implementationTechnology = "Messaging"
+}
+
+// With a colon it is possible (optionally) to add a relationship name to the specification
+ContractsContext [P]<->[P] ClaimsContext : ContractClaimRelationship {
+  implementationTechnology = "Messaging"
+}
 ```

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Published Language.md

@@ -1,5 +1,5 @@
-```cml
-PolicyManagementContext [D,CF]<-[U,OHS,PL] CustomerManagementContext {
-  implementationTechnology = "RESTful HTTP"
-}
+```cml
+PolicyManagementContext [D,CF]<-[U,OHS,PL] CustomerManagementContext {
+  implementationTechnology = "RESTful HTTP"
+}
 ```

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Shared Kernel (SK).md

@@ -1,13 +1,13 @@
-```cml
-CargoBookingContext [SK]<->[SK] VoyagePlanningContext {
-  implementationTechnology = "Java Library"
-}
-
-argoBookingContext Shared-Kernel VoyagePlanningContext {
-  implementationTechnology = "Java Library"
-}
-
-CargoBookingContext Shared-Kernel VoyagePlanningContext : BookingVoyageRelationship {
-  implementationTechnology = "Java Library"
-}
+```cml
+CargoBookingContext [SK]<->[SK] VoyagePlanningContext {
+  implementationTechnology = "Java Library"
+}
+
+argoBookingContext Shared-Kernel VoyagePlanningContext {
+  implementationTechnology = "Java Library"
+}
+
+CargoBookingContext Shared-Kernel VoyagePlanningContext : BookingVoyageRelationship {
+  implementationTechnology = "Java Library"
+}
 ```

package/template/.claude/skills/context-map/reference/Context Map.md

@@ -1,63 +1,63 @@
-A context map contains bounded contexts and defines their relationships.
-
-```cml
-ContextMap DDDSampleContextMap {
-  type SYSTEM_LANDSCAPE
-  state AS_IS
-//  type = SYSTEM_LANDSCAPE
-//  state = AS_IS
-
-  contains CargoBookingContext, VoyagePlanningContext, LocationContext
-//  contains CargoBookingContext
-//  contains VoyagePlanningContext
-//  contains LocationContext
-
-  CargoBookingContext [SK]<->[SK] VoyagePlanningContext
-}
-```
-A context map can be of one of the following `type`s:
-- `SYSTEM_LANDSCAPE` represents the default type of context map in which the bounded contexts represent software systems (or applications).
-- `ORGANIZATIONAL` map (or ‘team map’) illustrates the relationships between teams.
-
-The `state` expressing whether the given context map represents the current or a desired state:
-- `AS_IS`: Current State
-- `TO_BE`: Desired State
-[[Bounded Context Relationship]]
-# Relationship Roles
-You can further specify the relationship roles such as Open Host Service (OHS) or Anti-Corruption Layer (ACL) within the brackets. Roles must always be specified behind the U (upstream) and the D (downstream) if they are not omitted.
-
-```cml
-VoyagePlanningContext [D,ACL]<-[U,OHS,PL] LocationContext
-```
-
-Upstream roles:
--  Open Host Service (OHS)
--  Published Language (PL)
-The patterns OHS and PL can only be implemented by the upstream context in an upstream-downstream relationship. The upstream context always provides and exposes a certain functionality. The downstream context uses and consumes this services and does not expose parts of his/her own domain model. If this was the case and the upstream used this functionality, the definition that the upstream is independent of the downstream would be contradicted.
-
-Downstream roles:
-- Conformist (CF) 
-- Anticorruption Layer (ACL).
-# Relationship Attributes
-`implementationTechnology`: Within the body of the declaration, it is possible to specify the implementation technology used to realize this relationship:
-
-`downstreamRights`: defines which governance rights, and therefore which influence, the downstream has on the upstream within the specified relationship:
-The possible governance rights values are:
-- INFLUENCER
-- OPINION_LEADER
-- VETO_RIGHT
-- DECISION_MAKER
-- MONOPOLIST
-
-`exposedAggregates`: offers the possibility to declare which Aggregates of the upstream bounded context are exposed in order to realize this relationship. The attribute takes a comma-separated list of references to Aggregates. The referenced Aggregates must be part of the upstream context of the relationship.
-
-```cml
-VoyagePlanningContext [D,ACL]<-[U,OHS,PL] LocationContext {
-    implementationTechnology = "RESTful HTTP"
-    downstreamRights = VETO_RIGHT
-    exposedAggregates = Customers, Addresses
-}
-```
-
-[[Bounded Context]]
+A context map contains bounded contexts and defines their relationships.
+
+```cml
+ContextMap DDDSampleContextMap {
+  type SYSTEM_LANDSCAPE
+  state AS_IS
+//  type = SYSTEM_LANDSCAPE
+//  state = AS_IS
+
+  contains CargoBookingContext, VoyagePlanningContext, LocationContext
+//  contains CargoBookingContext
+//  contains VoyagePlanningContext
+//  contains LocationContext
+
+  CargoBookingContext [SK]<->[SK] VoyagePlanningContext
+}
+```
+A context map can be of one of the following `type`s:
+- `SYSTEM_LANDSCAPE` represents the default type of context map in which the bounded contexts represent software systems (or applications).
+- `ORGANIZATIONAL` map (or ‘team map’) illustrates the relationships between teams.
+
+The `state` expressing whether the given context map represents the current or a desired state:
+- `AS_IS`: Current State
+- `TO_BE`: Desired State
+[[Bounded Context Relationship]]
+# Relationship Roles
+You can further specify the relationship roles such as Open Host Service (OHS) or Anti-Corruption Layer (ACL) within the brackets. Roles must always be specified behind the U (upstream) and the D (downstream) if they are not omitted.
+
+```cml
+VoyagePlanningContext [D,ACL]<-[U,OHS,PL] LocationContext
+```
+
+Upstream roles:
+-  Open Host Service (OHS)
+-  Published Language (PL)
+The patterns OHS and PL can only be implemented by the upstream context in an upstream-downstream relationship. The upstream context always provides and exposes a certain functionality. The downstream context uses and consumes this services and does not expose parts of his/her own domain model. If this was the case and the upstream used this functionality, the definition that the upstream is independent of the downstream would be contradicted.
+
+Downstream roles:
+- Conformist (CF) 
+- Anticorruption Layer (ACL).
+# Relationship Attributes
+`implementationTechnology`: Within the body of the declaration, it is possible to specify the implementation technology used to realize this relationship:
+
+`downstreamRights`: defines which governance rights, and therefore which influence, the downstream has on the upstream within the specified relationship:
+The possible governance rights values are:
+- INFLUENCER
+- OPINION_LEADER
+- VETO_RIGHT
+- DECISION_MAKER
+- MONOPOLIST
+
+`exposedAggregates`: offers the possibility to declare which Aggregates of the upstream bounded context are exposed in order to realize this relationship. The attribute takes a comma-separated list of references to Aggregates. The referenced Aggregates must be part of the upstream context of the relationship.
+
+```cml
+VoyagePlanningContext [D,ACL]<-[U,OHS,PL] LocationContext {
+    implementationTechnology = "RESTful HTTP"
+    downstreamRights = VETO_RIGHT
+    exposedAggregates = Customers, Addresses
+}
+```
+
+[[Bounded Context]]
 [[Semantic Rules]]

package/template/.claude/skills/context-map/reference/Domain/Domain.md

@@ -1,30 +1,30 @@
-Domains are defined on the root level of a CML file.
-They provide a container to specify all subdomains which are then referenced on a bounded context with the `implements` keyword.
-A bounded context can also implement the compete domain.
-
-```cml
-/* Syntax example: Domain and Subdomains */
-Domain Insurance {
-  domainVisionStatement = "Insurance domain vision statement ..."
-
-  Subdomain CustomerManagementDomain {
-    type = CORE_DOMAIN
-    domainVisionStatement = "Subdomain managing everything customer-related."
-
-    Entity Customer {
-      String firstname
-      String familyname
-    }
-
-    /* Add more entities ... */
-  }
-
-  Subdomain ContractManagementDomain {}
-
-  /* Add more subdomains ... */
-}
-```
-[[domainVisionStatement]]
-[[Domain-Driven Design/Context Map/Domain/type|type]]
-[[supports]]
-
+Domains are defined on the root level of a CML file.
+They provide a container to specify all subdomains which are then referenced on a bounded context with the `implements` keyword.
+A bounded context can also implement the compete domain.
+
+```cml
+/* Syntax example: Domain and Subdomains */
+Domain Insurance {
+  domainVisionStatement = "Insurance domain vision statement ..."
+
+  Subdomain CustomerManagementDomain {
+    type = CORE_DOMAIN
+    domainVisionStatement = "Subdomain managing everything customer-related."
+
+    Entity Customer {
+      String firstname
+      String familyname
+    }
+
+    /* Add more entities ... */
+  }
+
+  Subdomain ContractManagementDomain {}
+
+  /* Add more subdomains ... */
+}
+```
+[[domainVisionStatement]]
+[[Domain-Driven Design/Context Map/Domain/type|type]]
+[[supports]]
+

package/template/.claude/skills/context-map/reference/Domain/supports.md

@@ -1,34 +1,34 @@
-The `supports` keyword specifies which user requirements a Subdomain implements.
-
-```cml
-/* Syntax example for Subdomain that supports specific user requirements: */
-Domain Insurance {
-  domainVisionStatement = "Insurance domain vision statement ..."
-
-  Subdomain CustomerManagementDomain supports CreateCustomers, CreateCustomerAddresses {
-    type = CORE_DOMAIN
-    domainVisionStatement = "Subdomain managing everything customer-related."
-
-    Entity Customer {
-      String firstname
-      String familyname
-    }
-  }
-
-}
-
-UserStory CreateCustomers {
-  As an "Insurance Employee"
-    I want to "create" a "Customer" with its "firstname", "lastname"
-  so that "I am able to manage the customers data and offer them insurance contracts."
-}
-
-UserStory CreateCustomerAddresses {
-  As an "Insurance Employee"
-    I want to "create" an "Address" for a "Customer"
-    I want to "update" an "Address" for a "Customer"
-  so that "I am able to manage the customers addresses."
-}
-```
-
+The `supports` keyword specifies which user requirements a Subdomain implements.
+
+```cml
+/* Syntax example for Subdomain that supports specific user requirements: */
+Domain Insurance {
+  domainVisionStatement = "Insurance domain vision statement ..."
+
+  Subdomain CustomerManagementDomain supports CreateCustomers, CreateCustomerAddresses {
+    type = CORE_DOMAIN
+    domainVisionStatement = "Subdomain managing everything customer-related."
+
+    Entity Customer {
+      String firstname
+      String familyname
+    }
+  }
+
+}
+
+UserStory CreateCustomers {
+  As an "Insurance Employee"
+    I want to "create" a "Customer" with its "firstname", "lastname"
+  so that "I am able to manage the customers data and offer them insurance contracts."
+}
+
+UserStory CreateCustomerAddresses {
+  As an "Insurance Employee"
+    I want to "create" an "Address" for a "Customer"
+    I want to "update" an "Address" for a "Customer"
+  so that "I am able to manage the customers addresses."
+}
+```
+
 [[UserStory]]

package/template/.claude/skills/context-map/reference/Domain/type.md

@@ -1,3 +1,3 @@
-CORE_DOMAIN
-SUPPORTING_DOMAIN
-GENERIC_SUBDOMAIN
+CORE_DOMAIN
+SUPPORTING_DOMAIN
+GENERIC_SUBDOMAIN