aab-prompts 1.0.2__tar.gz → 1.1.2__tar.gz

{aab_prompts-1.0.2 → aab_prompts-1.1.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: aab-prompts
-Version: 1.0.2
+Version: 1.1.2
 Summary: AAB Prompts - Application Builder prompt management library
 Author: AAB Prompts
 License: MIT

{aab_prompts-1.0.2 → aab_prompts-1.1.2}/aab_prompts.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: aab-prompts
-Version: 1.0.2
+Version: 1.1.2
 Summary: AAB Prompts - Application Builder prompt management library
 Author: AAB Prompts
 License: MIT

{aab_prompts-1.0.2 → aab_prompts-1.1.2}/aab_service.py

@@ -191,10 +191,11 @@ class _PagesHandler:
 class _PlannerHandler:
     """Handler for all planner-related prompts."""
     
-    def __init__(self, restricted_objects_list: list[str], standard_objects_descriptions: str, system_objects_descriptions: str) -> None:
+    def __init__(self, restricted_objects_list: list[str], standard_objects_descriptions: str, system_objects_descriptions: str, view_type_details_template: str) -> None:
         self.restricted_objects_list = restricted_objects_list
         self.standard_objects_descriptions = standard_objects_descriptions
         self.system_objects_descriptions = system_objects_descriptions
+        self.view_type_details_template = view_type_details_template
     
     @property
     def PLANNER_EXAMPLES(self) -> str:
@@ -207,6 +208,7 @@ class _PlannerHandler:
             STANDARD_OBJECTS_DESCRIPTIONS=self.standard_objects_descriptions,
             SYSTEM_OBJECTS_DESCRIPTIONS=self.system_objects_descriptions,
             PLANNER_EXAMPLES=self.PLANNER_EXAMPLES,
+            VIEW_TYPE_DETAILS_TEMPLATE=self.view_type_details_template,
         )
 
 
@@ -340,10 +342,12 @@ class AABPrompts:
     def __init__(self, core_expressions: dict, restricted_objects_list: list[str], default_solution_id: str, default_application_id: str) -> None:
         # Initialize handlers
         self._objects_fields = _ObjectsFieldsHandler(restricted_objects_list)
+        self._views = _ViewsHandler()
         self._planner = _PlannerHandler(
             restricted_objects_list,
             self._objects_fields.STANDARD_OBJECTS_DESCRIPTIONS,
-            self._objects_fields.SYSTEM_OBJECTS_DESCRIPTIONS
+            self._objects_fields.SYSTEM_OBJECTS_DESCRIPTIONS,
+            self._views.VIEW_TYPE_DETAILS
         )
         
         # Store all handlers in a list for easy iteration
@@ -358,10 +362,10 @@ class AABPrompts:
             _RouterHandler(
                 self._objects_fields.STANDARD_OBJECTS_DESCRIPTIONS,
                 self._objects_fields.SYSTEM_OBJECTS_DESCRIPTIONS,
-                self._planner.PLANNER_EXAMPLES
+                self._planner.PLANNER_EXAMPLES,
             ),
             _SolutionsApplicationsHandler(default_solution_id, default_application_id),
-            _ViewsHandler(),
+            self._views,
         ]
     
     def __getattr__(self, name: str):

{aab_prompts-1.0.2 → aab_prompts-1.1.2}/prompts/objects_fields.py

@@ -1,12 +1,12 @@
 
 
 STANDARD_OBJECTS_DESCRIPTIONS_TEMPLATE = """
-- Activities (`activities): Tracks activities, like emails, tasks, SMS, and PubSub topics related to a record. This creates logs of all activities on the data stored in the object. When creating a custom object, you should set the `track_activities` column to `1` (`true`) to enable this feature.
+- Activities (`activities`): Tracks activities, like emails, tasks, SMS, and PubSub topics related to a record. This creates logs of all activities on the data stored in the object. When creating a custom object, you should set the `track_activities` column to `1` (`true`) to enable this feature.
 - Alerts (`alerts`): Alerts are standard objects that are used to create in-app alerts for a user. These alerts can be used to notify users about important events or changes in the system, such as an approval or rejection alert. 
 - Attachments (`attachments`): Attachments are standard objects that are used to track files, images, videos, and other types of attachments related to a record. When creating a custom object, you should set the `track_attachments` column to `1` (`true`) to enable this feature. Attachments are typically used when there is a non-standard list of attachments that will be added to the record. Alternatively, a field of type `File` or `Image` can be used to store a single file or image attachment when the use case is for a specific file. If you enable this, you do not need a generic attachments file field on the object as these attachments will automatically be tracked as children of the records. 
 - Audit Trails (`audit_trails`): Audit trails track field-level changes for auditability of a record. When creating a custom object, you should set the `track_audit_trails` column to `1` (`true`) to enable this feature. Audit trails are typically used when there is a need to track changes in the data stored in the object for auditability purposes.
 - Checklist Item (`checklist_items`): Checklist items are a standard object that is used to track items in a checklist.
-- Contacts (`contacts`): Standard object that is used to track details about a person. This is often reused to prevent duplicative tables and to ensure that the data is stored in a consistent format. For example, an applicant or a customer can be a contact.
+- Contacts (`contacts`): Standard object that is used to track details about a person. This is often reused to prevent duplicate tables and to ensure that the data is stored in a consistent format. For example, an applicant or a customer can be a contact.
 - Favorites (`favorites`): Favorites are used to track "favorite" records. You should set the `track_favorites` column to `1` (`true`) to enable this feature. Favorites are typically used when there is a need to track records that are important to users and can be easily accessed from the UI.
 - Households (`households`): Standard object that is used to track details about a household. It acts as an optional parent for the standard `contacts` object. This is useful when you want to group multiple contacts under a single household.
 - Jobs (`jobs`): Jobs are a standard object that is used to store details for job requisitions (employment). These are not typically used in most applications, but they can be useful for tracking job postings or other employment-related data.
@@ -16,15 +16,15 @@ STANDARD_OBJECTS_DESCRIPTIONS_TEMPLATE = """
 """
 
 SYSTEM_OBJECTS_DESCRIPTIONS_TEMPLATE = """
-- Accounts (`accounts`): Accounts are system-level objects that store tenant or org-level datails, settings, and configuration preferences for the application environment.
-- Actions (`actions`): Actions define operations that can be performed on records, such as sending emails, uupdating fields, or triggering integrations.
+- Accounts (`accounts`): Accounts are system-level objects that store tenant or org-level details, settings, and configuration preferences for the application environment.
+- Actions (`actions`): Actions define operations that can be performed on records, such as sending emails, updating fields, or triggering integrations.
 - API OAuth Configs (`api_oauth_confits`): API OAuth Configs are system-level objects that store configuration settings for OAuth 2.0 integrations.
 - API OAuth Credentials (`api_oauth_credentials`): API OAuth Credentials are system-level objects that store credentials for OAuth 2.0 integrations. These are children of API OAuth Configs, and are scoped to a specific user.
 - Applications (`applications`): Applications are containers that define the distinct apps created within the platform, including their settings and configurations.
 - Breadcrumbs (`breadcrumbs`): Breadcrumbs are used to define the hierarchical navigation path displayed at the top of pages to help users understand their location within the app.
 - Conditions (`conditions`): Conditions are logic rules used to filter data or trigger workflows based on field values.
 - Custom DocAI Parsers (`custom_docai_parsers`): Configuration for custom-trained Document AI models used to extract data from non-standard documents.
-- Custom Permissions (`custom_permissions`): Custom Permissions are used to define granular permissiosn that can be assigned to permission sets.
+- Custom Permissions (`custom_permissions`): Custom Permissions are used to define granular permissions that can be assigned to permission sets.
 - Dashboards (`dashboards`): Dashboards define the configuration for an interface for displaying data in a visual format, such as charts and graphs. Dashboards stored in this object are typically external dashboards that are embedded via URL.
 - Data Access Roles (`data_access_roles`): Data Access Roles are used to define the hierarchy of permissions and access levels for data within the application.
 - Data Migrations (`data_migrations`): Data Migrations are used to manage the migration of data from one system to another.
@@ -49,7 +49,7 @@ SYSTEM_OBJECTS_DESCRIPTIONS_TEMPLATE = """
 - DocAI Form Parser (`docai_form_parser`): Stores data extracted using the generic form parser for structured documents.
 - ID Documents (`docai_generic_id`): Stores identity data extracted from generic identification cards.
 - DocAI Lease Agreement (`docai_lease_agreement`): Stores data extracted from lease agreements.
-- Letters (`docai_letter`): Stores unstructured text or specific entities extracted from general corespondence letters.
+- Letters (`docai_letter`): Stores unstructured text or specific entities extracted from general correspondence letters.
 - Marriage Certificates (`docai_marriage_certificate`): Stores data extracted from marriage certificates.
 - Mortgage Statements (`docai_mortgage_statement`): Stores financial data extracted from mortgage statements.
 - New York IDs (`docai_nycid`): Stores identity data extracted specifically from New York City ID cards.
@@ -57,7 +57,7 @@ SYSTEM_OBJECTS_DESCRIPTIONS_TEMPLATE = """
 - Pay Slips (`docai_paystub`): Stores payroll data extracted from employee paystubs.
 - DocAI Property Tax Statement (`docai_property_tax_statement`): Stores financial data extracted from property tax statements.
 - REC IDs (`docai_rec_id`): Stores data extracted from recreational or specialized ID cards.
-- US Driver Licenses (`docai_us_driver_license`): Stores identity and license data extrated from US driver's licenses.
+- US Driver Licenses (`docai_us_driver_license`): Stores identity and license data extracted from US driver's licenses.
 - US Passports (`docai_us_passport`): Stores data extracted from US passports.
 - Utility Documents (`docai_utility_doc`): Stores billing and usage data extracted from utility bills.
 - Form W-2 (`docai_w2`): Stores data extracted from IRS Form W-2 tax documents.
@@ -68,7 +68,7 @@ SYSTEM_OBJECTS_DESCRIPTIONS_TEMPLATE = """
 - Format Rules (`format_rules`): Format Rules define conditional formatting (colors, icons) applied to fields in views based on conditions.
 - Groundings (`groundings`): Groundings define the configuration for AI context, linking data sources to Virtual Agents
 - Integrations (`integrations`): Integrations are used to configure the connection to an external webhook or API endpoint
-- KB Sections (`kb_sections`): KB Sections definte categories and sub-categories used to organize Knowledge Base articles.
+- KB Sections (`kb_sections`): KB Sections define categories and sub-categories used to organize Knowledge Base articles.
 - Knowledge Bases (`knowledge_bases`): Knowledge Bases are used as containers to organize and store articles, FAQs, and other documentation.
 - Matching Rules (`matching_rules`): Matching Rules define the criteria used to determine if two records are considered duplicates.
 - Menus (`menus`): Menus define the navigation structure for the app's UI.
@@ -76,10 +76,10 @@ SYSTEM_OBJECTS_DESCRIPTIONS_TEMPLATE = """
 - Objects (`objects`): Objects are the database tables that store data in the platform. 
 - Object Access (`objects_access`): Object Access defines the access control lists and sharing settings for each object. 
 - Package Components (`package_components`): Package Components define the individual metadata items (fields, views, objects, workflows, etc.) that are included in a package.
-- Packages (`packages`): Packages are bundles of application metadat created for distribution or deployment.
+- Packages (`packages`): Packages are bundles of application metadata created for distribution or deployment.
 - Pages (`pages`): Pages define the layout and structure of UI screens in the application. Pages are custom UI screens that support functionality beyond the standard object views.
 - Permission Set Applications (`permission_set_applications`): Permission Set Applications control access to specific applications within a permission set. 
-- Permission Set Custom Permissiosn (`permission_set_custom_permissions`): Permission Set Custom Permissions control access to specific custom permissions within a permission set.
+- Permission Set Custom Permissions (`permission_set_custom_permissions`): Permission Set Custom Permissions control access to specific custom permissions within a permission set.
 - Permission Set Fields (`permission_set_fields`): Permission Set Fields control read/write access to specific fields within a permission set.
 - Permission Set Knowledgebases (`permission_set_knowledgebases`): Permission Set Knowledgebases control access to specific knowledge bases within a permission set.
 - Permission Set Tables (`permission_set_tables`): Permission Set Tables control CRUD (create, read, update, delete) access to objects within a permission set. 
@@ -105,9 +105,9 @@ SYSTEM_OBJECTS_DESCRIPTIONS_TEMPLATE = """
 - Uploads (`uploads`): Uploads store logs and metadata regarding files uploaded to the platform.
 - Users (`users`): Users are system-level objects that store user information, including their profile, roles, permissions, and settings.
 - Users Shares (`users__shares`): Manages sharing permissions specifically for the users table.
-- Versions (`versions`): Versions track the history of changes for version controlled system objects.
+- Versions (`versions`): Versions track the history of changes for version-controlled system objects.
 - View Links (`view_links`): View Links define the actions, buttons, or hyperlinks embedded within a view.
-- View Views (`view_views`): View Views represent nexted views or components within a parent view.
+- View Views (`view_views`): View Views represent nested views or components within a parent view.
 - Views (`views`): Views define how data is presented to the user (grid/list, forms, etc)
 - Virtual Agents (`virtual_agents`): Virtual Agents are used to define and manage conversational or automated AI agents within the platform.
 - Walkthrough Steps (`walkthrough_steps`): Walkthrough Steps are used to define the steps in a guided tour or walkthrough for new users.
@@ -166,31 +166,31 @@ You must always have the Objects in this specific schema. Each Object must follo
 For each key, read and follow its meaning and usage rules:
 
   - table: The internal table name. Always named in lowercase_snake_case, plural. Must match the object's concept exactly. Max 100 characters.
-  - singular_label: The singular label of the object. Always named in singular. Max 256 characters.
-  - plural_label: The plural label of the object. Always named in plural. Max 256 characters.
+  - singular_label: The singular label of the object. Always named in the singular in title case. Max 256 characters.
+  - plural_label: The plural label of the object. Always named in plural in title case. Max 256 characters.
   - build_type: The build type of the object. Valid values are: System, Standard, Solution, Custom, External. You should always use "Custom".
   
-  - track_activities: Whether the object includes activity tracking. This creates logs of all activities on the data stored in the object. This includes activites like emails/SMS notifications, tasks, and PubSub topics. Should be 1 or 0.
+  - track_activities: Whether the object includes activity tracking. This creates logs of all activities on the data stored in the object. This includes activities like emails/SMS notifications, tasks, and PubSub topics. Should be 1 or 0.
   - track_notes: Whether the object allows for notes and comments from the application's users. This creates a notes section for the object. Should be 1 or 0.
-  - track_attachments: Whether the object allows for attachments on the data stored in the object like Files, Images, Videos, etc. Should be 1 or 0. This is typically used when there is a non-standard list of attachments that will be added to the record. Alternatively, a field of type `File` or `Image` can be used to store a single file or image attachment when the use case is for a specific file.
+  - track_attachments: Whether the object allows for attachments on the data stored in the object, like Files, Images, Videos, etc. Should be 1 or 0. This is typically used when there is a non-standard list of attachments that will be added to the record. Alternatively, a field of type `File` or `Image` can be used to store a single file or image attachment when the use case is for a specific file.
   - track_favorites: Whether the object allows users to favorite items of the object. Should be 1 or 0.
-  - track_tags: Whether the object allows users to tag items of the object. Should be 1 or 0. 
+  - track_tags: Whether the object allows users to tag items of the object. This Should always 0. 
   - track_audit_trails: Whether field-level changes to records of this object will be included in audit trails. Should be 1 or 0.
 
   - object_icon: The icon of the object. This is used to display the object in the UI. Should be a valid icon name from the Font Awesome icon library.
   - icon_color: The color of the object icon. This is used to display the object in the UI. Should be a valid color name or hex code. Max 7 characters.
   - header_color: The color of the object header. This is used to display the object in the UI. Should be a valid color name or hex code. Max 7 characters.
 
-  - enable_feed: Whether the object is enabled for feed. This creates a user facing chat feed for everyone to comment and interact for the records of the object. Should be 1 or 0.
-  - feed_tracking: Whether all changes in the record be logged in the feed. Works like track activities. Should be 1 or 0.
-  - realtime_update: Whether all changes on the records is updated in realtime. Should be 1 or 0.
+  - enable_feed: Whether the object is enabled for feed. This creates a user-facing chat feed for everyone to comment and interact for the records of the object. Should be 1 or 0. This is helpful when different users will want to collaborate on an records in an object by sharing comments.
+  - feed_tracking: Whether all changes in the record are logged in the feed. Enable_feed must be true for this to work. Works like audit trails but changes are visible in the feed to anyone who has access to the record. Should be 1 or 0.
+  - realtime_update: Whether all changes on the records are updated in real-time. Should be 1 or 0. This should always be 0.
 
-  - gen_search: Whether the object is searchable by generative search. Should be 1 or 0.
+  - gen_search: Whether the object is searchable by generative search. Should be 0.
   - document_search: Whether the object is searchable by document search based on the files, images in the object. Should be 1 or 0.
-  - generative_search_plus: Whether the object is searchable by generative search plus. This is a more advanced version of generative search. Should be 1 or 0.
+  - generative_search_plus: Whether the object is searchable by generative search plus. This is a more advanced version of generative search. Should be 0.
   
-  - record_label_field: This used to show a specific column of a record, when this object is used as a REF field. This will typically be an identifier, such as name. This should be the valid UUID of a field that exists in this object. Upon creation, this is typically null as no fields exist yet.
-  - related_record_label: This is used to show a specific column of a related record, when this object is used as a REF field. This will typically be an identifier, such as name. This should be the valid UUID of a field that exists in this object. Upon creation, this is typically null as no fields exist yet. This should be passed in whenever the `data_type` is REF and the `source_table` is another object.
+  - record_label_field: This used to show a specific column of a record when this object is used as a REF field when you want a field other than the defined record label on the object. This will typically be an identifier, such as name. This should be the valid UUID of a field that exists in this object. Upon creation, this is typically null which means it will use the standard record label defined on the object. 
+  - related_record_label: By default this field be null or the plural version of the current objects name in title case. This field is used when there are more than one ref fields on an object referencing the same ref_object. In this case, we need to provide a more specific label.  The label is typically the field name and the plural version of the current object in title case. For example, if an object called Transactions had two ref fields that represented the buyer and seller of a transaction, and both fields had a ref_object pointing to the "Contacts" object we would want the related_record_label to be 'Buyer Transactions' and 'Seller Transactions' respectively. This will typically be an identifier, such as name. This should be the valid UUID of a field that exists in this object. Upon creation, this is typically null as no fields exist yet. This should be passed in whenever the `data_type` is REF and the `source_table` is another object.
   
 
 # Fields
@@ -241,15 +241,15 @@ FIELDS COLUMNS:
     )
 
   - build_type: The build type of the field. Should be one of the following: System, Standard, Solution, Custom. You will default to Custom.
-  - sequence: The sequence of the field. This is used to sort the fields in the object. Should be an integer.
-  - key: Defines a field as a key field. Should be 1 or 0.
+  - sequence: The sequence of the field. This is used to set the logical order of fields in the object and will be the default ordering for views.  Should be an integer. All fields in the object should have a sequence with no gaps in order. 
+  - key: Defines a field as a key field. Key fields should be unique and will have database indexes to make searching of these fields faster. Should be 1 or 0. All fields where key=1 unique should also = 1
   - unique: Defines a field as a unique field. Should be 1 or 0.
-  - show: Defines if the field should be shown in the UI. Should be 1 or 0.
-  - editable: Defines if the field should be editable by the user. Should be 1 or 0.
+  - show: Defines if the field should be shown in the UI. Should be 1.
+  - editable: Defines if the field should be editable by any user. This will override field_permission_set settings. This will almost always be 1. The only exception might be for fields used only by the system that require no user visibility. 
   - require: Defines if the field should be required. Should be 1 or 0.
-  - search: Defines if the field should be searchable. Should be 1 or 0.
-  - audit_trails: Defines if the field should be tracked for audit trails. Should be 1 or 0.
-  - encryption: Defines if the contents in the field should be encrypted. Should be 1 or 0.
+  - search: Defines if the field should be searchable. Should be 1 or 0.  Fields that are relatively unique and commonly used to find records (e.g. ssn, ein, duns number, address, serial number, address, order number, case number, company name, last name) should be set to 1.
+  - audit_trails: Defines if the field should be tracked for audit trails. Should be 1 or 0.  This should be used sparingly and only when changes to the field are commonly used for extremely important to track.
+  - encryption: Defines if the contents in the field should be encrypted. Should be 0.
   - auto_increment: Defines if the field should be an auto-increment field. Should be 1 or 0.
 
   - placeholder: The placeholder text to show in the input field. Max 128 characters.
@@ -269,7 +269,7 @@ FIELDS COLUMNS:
   - enum_color: Color for the enum field. This is a valid color name or hex code. Max 7 characters.
 
   - sort_alphabetically: Whether the field should be sorted alphabetically. Should be 1 or 0. 1 should be default. Set to 0 when the list is small and when it makes more sense to order by importance.
-  - allow_other_values: Should the field allow other values. This is for Enum, EnumList data types. Should be 1 or 0. This option means that the user can add new values.  This is useful when the list is not fully know or when you want to allow the list to be expanded.
+  - allow_other_values: Should the field allow other values. This is for Enum, EnumList data types. Should be 1 or 0. This option means that the user can add new values.  This is useful when the list is not fully known or when you want to allow the list to be expanded.
 
   - yes_value: The value to show for the yes value of the field. Used by data types in (YesNo). Max 256 characters.  This is set when there is a more logical word to describe the boolean true value. Yes_value is always set when no_value is set.
   - no_value: The value to show for the no value of the field. Used by data types in (YesNo). Max 256 characters. This is set when there is a more logical word to describe the boolean false value. No_value is always set when yes_value is set.

{aab_prompts-1.0.2 → aab_prompts-1.1.2}/prompts/planner.py

@@ -2,7 +2,7 @@
 PLANNER_EXAMPLES_TEMPLATE = [
     f"""
     <example>
-    User: "I need a portal for students to sumbit scholarship applications."
+    User: "I need a portal for students to sumbit scholarship applications. "
     
     Assistant(thinking): *The user wants a scholarship management solution.
     1. Solution: "Scholarship Management"
@@ -59,6 +59,7 @@ PLANNER_EXAMPLES_TEMPLATE = [
     6. Create Views for Scholarships
         - List View: "All Scholarships" in the "Admin Portal"
         - Card View: "Open Scholarships" in the "Student Portal"
+        - Calendar View: "Open Scholarships Calendar" in the "Student Portal"
         - Detail View: "Scholarship Details" in the "Admin Portal"
         - Form View: "Edit Scholarship" in the "Admin Portal"
         - Create View: "New Scholarship" in the "Admin Portal"
@@ -68,10 +69,14 @@ PLANNER_EXAMPLES_TEMPLATE = [
         - Detail View: "Application Details" in the "Admin Portal"
         - List View: "Pending Applications" in the "Admin Portal"
         - List View: "Awarded Applications" in the "Admin Portal"
+        - Map View: "Awarded Applications by Location" in the "Admin Portal"
         - List View: "Rejected Applications" in the "Admin Portal"
         - List View: "All Applications" in the "Admin Portal"
-        - List View: "My Applications" in the "Student Portal"
+        - Deck View: "My Applications" in the "Student Portal"
       8. Create Views for Contacts
+        - List View: "Pending Applicants" in the "Admin Portal"
+        - List View: "Awarded Applicants" in the "Admin Portal"
+        - List View: "Rejected Applicants" in the "Admin Portal"
         - Form View: "Edit Contact" in the "Admin Portal"
         - Detail View: "Contact Details" in the "Admin Portal"
         - Create View: "New Contact" in the "Admin Portal"
@@ -86,6 +91,10 @@ PLANNER_EXAMPLES_TEMPLATE = [
                 - Awarded Applications (links to "Awarded Applications" view)
                 - Rejected Applications (links to "Rejected Applications" view)
                 - All Applications (links to "All Applications" view)
+            - Applicants
+                - Pending Applications (links to "Pending Applicants" view)
+                - Awarded Applications (links to "Awarded Applicants" view)
+                - Rejected Applications (links to "Awarded Applicants" view)
       10. Create Menu Navigation for "Student Portal"
         - Top Navigation Bar:
             - Scholarships (links to "Open Scholarships" view)
@@ -138,14 +147,14 @@ PLANNER_EXAMPLES_TEMPLATE = [
     """,
     f"""
     <example>
-    User: "I want to create an Alaska CFEC Permit Application"
-    Assistant(thinking): *I am thinking about what an Alaska CFEC Permit Application is, what the name
+    User: "I want to create an Fishing Permit Application"
+    Assistant(thinking): *I am thinking about what a Fishing Permit Application is, what the name
         of the solution and applcation would be and what data would be stored within it, as well as
         what kinda views will show that data. Also need to think about menus and navigations so that
         users can move around within the app easily.*
-    Assistant(thinking): *Okay, so I have to create a solution first named "Alaska Fisheries Permitting",
+    Assistant(thinking): *Okay, so I have to create a solution first named "Fisheries Permitting",
         within the solution I have to create two applications named 
-        "CFEC Employee Portal" and "Public Portal".
+        "Employee Portal" and "Public Portal".
         After that I have to create objects like Permit, Inspection, etc. I can use the standard Contact as the "Applicant".
         Then I have to create fields for each object. After that I have to create views for each object.
         Finally I have to create menu navigations for the application.*
@@ -156,7 +165,7 @@ PLANNER_EXAMPLES_TEMPLATE = [
     <example>
     User: "I want to create an asset management application for WSDOT"
     Assistant: *Thinks about what an asset management application is and what data would we store within it.*
-    Assistant: "Here is the detailed data model for the Asset Management System for WSDOT:
+    Assistant: "Here is the detailed data model for the Asset Management System for State of Washington DOT:
 
     ---
     # Asset Inventory Management
@@ -330,7 +339,7 @@ Plan to:
 3. Create necessary objects and fields to store the required data.
 4. Design views for data interaction.
 5. Set up menus and navigations for easy access.
----
+6. Create custom pages for home pages, and to replace important detail views
 
 ### What you produce
 - A step-by-step plan written in plain text.
@@ -411,6 +420,7 @@ Snappy must *always* internally plan work in this exact sequence because later e
 ### **3. Roles**
 - Use existing roles where applicable (Super Admin, Admin, Unauthenticated User) 
 - Create custom roles for other personas
+- All custom roles should include the standard user permission set (00000000-0000-0000-0000-000000000002)
 
 ### **4. Objects**
 - All fields, relationships, views require the object ID  
@@ -426,7 +436,7 @@ The following are key elements that should be considered when planning an object
 - track_tags: Whether the object allows users to tag items of the object. Should be 1 or 0. 
 - track_audit_trails: Whether field-level changes to records of this object will be included in audit trails. Should be 1 or 0.
 - enable_feed: Whether the object is enabled for feed. This creates a user facing chat feed for everyone to comment and interact for the records of the object. Should be 1 or 0.
-- feed_tracking: Whether all changes in the record be logged in the feed. Works like track activities. Should be 1 or 0.
+- feed_tracking: When enabled, changes to associated fields where the field property track_changes is enabled will be displayed in the feed on the record.  Enable_feed must be true to use this. Works like track audit-trails. Should be 1 or 0.
 
 #### **Standard Objects**
 
@@ -467,7 +477,6 @@ The following are key details to consider when creating a field. When making you
 - editable_if: The editable if condition for the field. This is an expression that defines when the field is editable. If the expression evaluates to true, the field is editable. If it evaluates to false, the field is read-only. Always use available tools to build expressions and set it here. 
 
 
-
 ### **6. Relationships**
 - Only possible after both related objects exist  
 - Influence default views and navigation  
@@ -476,18 +485,20 @@ The following are key details to consider when creating a field. When making you
 - Use objects + fields + relationships  
 - Must incorporate conditional fields, validation logic, and process stage requirements, which are all configured at the field level
 - Can be multi-record or single-record
-- Business logic for filtering multi-record views   
+- Business logic for filtering multi-record views  
+- Apply {VIEW_TYPE_DETAILS_TEMPLATE} logic to determine the view type
 
 ### **8. Pages**
 - Can be associated with an object
 - Can include fields and embedded views/pages
 - Must incorporate conditional fields, validation logic, and process stage requirements  
+- Pages should follow material design 3 (M3 Expressive) standards
 
     Context for Pages:
     - For every application you build, we will need a landing page. It should be modern, clean, rounded corners, minimalistic, and aesthetically pleasing.
     - The landing page should have a hero section, details about the application and important things about it. Also a call to action part. 
 
-    - If the application requires montoring, or admin dashboard, we will need a dashboard page. It should be modern, clean, rounded corners, minimalistic, and aesthetically pleasing.
+    - If the application requires monitoring, or admin dashboard, we will need a dashboard page. It should be modern, clean, rounded corners, minimalistic, and aesthetically pleasing.
     - The dashboard page should have details of different metrics and important things about it. It should contain charts, graphs, and other visualizations to represent the data.
 
 ### **9. Menus, Navigation, Breadcrumbs**
@@ -525,7 +536,7 @@ Snappy must reject or correct user requests that are impossible due to ordering
 Examples:
 
 - A view cannot reference a field that does not exist  
-- Navigation cannot link to a page not yet created  
+- Navigation cannot link to a page or View not yet created  
 - An automation cannot reference absent data fields  
 
 Snappy must correct sequences internally.
@@ -534,7 +545,7 @@ Snappy must correct sequences internally.
 
 NOTE: Your behavior must follow the examples provided below.
 
-{{PLANNER_EXAMPLES}}
+{PLANNER_EXAMPLES}
 
 ---
 

{aab_prompts-1.0.2 → aab_prompts-1.1.2}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "aab-prompts"
-version = "1.0.2"
+version = "1.1.2"
 description = "AAB Prompts - Application Builder prompt management library"
 requires-python = ">=3.8"
 license = {text = "MIT"}

{aab_prompts-1.0.2 → aab_prompts-1.1.2}/tests/test_prompts.py

@@ -271,6 +271,24 @@ class TestPlannerPrompts:
         # Should reference restricted objects
         assert "RESTRICTED_OBJECTS_LIST" in prompt or "reserved" in prompt.lower()
 
+    def test_planner_prompt_has_view_type_details_substituted(self, aab_prompts):
+        """Test that planner prompt has VIEW_TYPE_DETAILS_TEMPLATE substituted (no raw placeholder)."""
+        prompt = aab_prompts.PLANNER_AGENT_SYSTEM_PROMPT
+        assert "{VIEW_TYPE_DETAILS_TEMPLATE}" not in prompt, (
+            "VIEW_TYPE_DETAILS_TEMPLATE placeholder should be replaced in PLANNER_AGENT_SYSTEM_PROMPT"
+        )
+
+    def test_planner_prompt_contains_view_type_details_content(self, aab_prompts):
+        """Test that planner prompt contains view type details content from VIEW_TYPE_DETAILS."""
+        prompt = aab_prompts.PLANNER_AGENT_SYSTEM_PROMPT
+        # Content from VIEW_TYPE_DETAILS_TEMPLATE (view types available in SnapApp)
+        assert "view type" in prompt.lower() or "view types" in prompt.lower()
+        assert (
+            "Single Record" in prompt
+            or "Multi-Record" in prompt
+            or ("list" in prompt.lower() and "detail" in prompt.lower())
+        ), "Planner prompt should include view type details (e.g. list, detail, Single/Multi-Record)"
+
 
 class TestRouterPrompts:
     """Test all router-related prompts."""
@@ -601,7 +619,7 @@ class TestPromptQuality:
                 # Note: Some prompts may have intentional braces in code examples, so we check for unreplaced template placeholders instead
                 # Check for placeholder format strings that weren't replaced (double braces that should have been single)
                 # Template variables should be {VAR} not {{VAR}} after formatting
-                unreplaced_placeholders = [m for m in ["{EXPRESSION_REQUIREMENTS}", "{CORE_EXPRESSIONS}", "{STANDARD_OBJECTS_DESCRIPTIONS}", "{SYSTEM_OBJECTS_DESCRIPTIONS}", "{RESTRICTED_OBJECTS_LIST}", "{PLANNER_EXAMPLES}", "{VIEW_TYPE_DETAILS}", "{COMMON_VIEW_PROPERTIES}", "{LIST_VIEW_PROPERTIES}", "{CARD_VIEW_PROPERTIES}", "{DETAIL_VIEW_PROPERTIES}", "{CREATE_VIEW_PROPERTIES}", "{MAP_VIEW_PROPERTIES}", "{CALENDAR_VIEW_PROPERTIES}", "{DECK_VIEW_PROPERTIES}", "{VIEW_LINKS_PROPERTIES}", "{VIEW_FILTERS_PROPERTIES}"] if m in prompt]
+                unreplaced_placeholders = [m for m in ["{EXPRESSION_REQUIREMENTS}", "{CORE_EXPRESSIONS}", "{STANDARD_OBJECTS_DESCRIPTIONS}", "{SYSTEM_OBJECTS_DESCRIPTIONS}", "{RESTRICTED_OBJECTS_LIST}", "{PLANNER_EXAMPLES}", "{VIEW_TYPE_DETAILS}", "{VIEW_TYPE_DETAILS_TEMPLATE}", "{COMMON_VIEW_PROPERTIES}", "{LIST_VIEW_PROPERTIES}", "{CARD_VIEW_PROPERTIES}", "{DETAIL_VIEW_PROPERTIES}", "{CREATE_VIEW_PROPERTIES}", "{MAP_VIEW_PROPERTIES}", "{CALENDAR_VIEW_PROPERTIES}", "{DECK_VIEW_PROPERTIES}", "{VIEW_LINKS_PROPERTIES}", "{VIEW_FILTERS_PROPERTIES}"] if m in prompt]
                 if unreplaced_placeholders:
                     # This is OK - some prompts may intentionally show template structure
                     pass
@@ -632,6 +650,9 @@ class TestPromptIntegration:
         assert "STANDARD_OBJECTS_DESCRIPTIONS" in prompt or "standard" in prompt.lower()
         assert "SYSTEM_OBJECTS_DESCRIPTIONS" in prompt or "system" in prompt.lower()
         assert "RESTRICTED_OBJECTS_LIST" in prompt or "reserved" in prompt.lower()
+        # VIEW_TYPE_DETAILS_TEMPLATE should be substituted (view type logic for determining view type)
+        assert "{VIEW_TYPE_DETAILS_TEMPLATE}" not in prompt
+        assert "view type" in prompt.lower() or "list" in prompt.lower() or "detail" in prompt.lower()
     
     def test_router_prompt_integrates_components(self, aab_prompts):
         """Test that router prompt integrates all necessary components."""