DYAD Pro - $20 (200 dyad credits)

Summary: three prompts with Claude Sonnet in Agent/Thinking mode until depletion.

Prompts:

Visit following URLs to learn how to work with tools I want to use for my website.

> activepieces ai skills Github Repo

> stripe AI Skills Github Repo

> travel products wholesaler AI Skills Github Repo 

Ok. I had the "search and filter" features working fine with the simple html file of my prototype (viewable at shop.downloadsim.com/index_deepseek.html"). I built more complex one with Google Gemini to hide the API keys, and to visually polish the appearance, for the website. Once I told Google Gemini to remove the dummy data, shit fell apart.

Now, if you think this Gemini-built website is usable, let me tell you more about my intent. You can tell me if what I intent to achieve is possible at all or at is least easy enough to not burn through the credits. You cost a lot more than Gemini or GPT or Qwen, so don't expect me to keep the "Agent v2" mode and pour money into recharging credits. This website is not supposed to cost a lot.

INTENT 1. The website has an AI agent feature to help customers choose the right eSIM. The agent was gonna be Google Gemini but he's fucking fired. I just want a tool in the backend where I can add some credentials for another AI to power the Ai Travel Guide tools.

INTENT 2. I am sick of these "Falls back to simulated ICCID if the API fails" type of bullshit by Gemini. If something fails, the page should just say something failed. I want any such bullshit data or fallback actions removed and make the website honest, so it will just describe what happened when something failed instead of trying to hide it by displaying some bullshit data.

INTENT 3. First thing I want to achieve if I decide to continue building onto the Google initiated website is to see the live data from esimaccess.com when I begin typing into search field and select to see products for those countries.

My eSIM wholesaler, eSIMaccess.com, uses what's called "packageCode" to keep track of products. The "packageCode" is basically its SKU. Each package, individually distinguishable product associated with each SKU, contains variables with somewhat overlapping values such as "location" and "locationCode" in the root directory of the data structure and another "locationCode" within what's called "locationNetworkList" directory in the root directory.

The "locationName" variable provides a value including names of all countries covered by the product. This was used to extract country names and generate country list. The API extracted country list was then compared with my own country list and (for countries not existing in the list extracted from product catalog but existing in my own list) mark the countries without associated products. I plan to use my own central collection of country data with 2-letter ISO country codes, and also with 3-letter custom country codes for localization and future product rollouts for un-serviced countries when I find additional vendors capable of servicing those places. I was also manipulating the region hierarchy in the backend "Geo-Domains" page.

The "location" variable contains a list of 2 letter country code for all countries serviced by the product, so it will have more than just a 2 letter code for any products that are for multiple countries.

The "locationCode" variable in the root directory provides one value even for products servicing multiple countries, but the value will be a custom code for products that are not servicing only one country: such as GL-139 for Global 139 Countries plan, or AS-12 for Asia 12 Countries plan, etc. This variable is available only as a part of "list packages" API action to obtain product catalog but not as a part of "allocated profiles" API action to obtain a list of active products and already procured (by prepaying to the wholesaler) products in my inventory. For a prototype, I used this root-locationCode to identify coverage of each product by looking at the first three letters of the product (since all single-country products have two-letter country code while multi-country products have "-" as the third letter of their locationCode: such as Greenland "GL" and Global 139 Countries "GL-139") to determine whether a product is single-country or multi-country product (for global/regional product filters).

The other locationCode that's inside the "locationNetworkList", which lists network profiles of every country serviced by the product, would always provide a 2 letter country code for every country a product services. In my basic HTML prototype, I used this locationCode within "locationNetworkList" identify countries associated with each product identifiable by the SKU (packageCode).

What do you think?