Learning PathModule

Extend it with AI (optional)

Use the commercetools-connect skill to add one more Message type, and check the result against acceptance criteria.

Ask about this Page
Copy for AI
View as Markdown

After completing this page, you should be able to:

  • Extend a Connector with an AI coding assistant and the commercetools-connect skill.

  • Verify AI-generated changes against acceptance checks and the Connect documentation.

This page is optional and ungraded. AI output differs from one learner to the next, so the page gives you the requirement and the acceptance checks, not the code. You decide whether the result is done by checking it, not by comparing it with a reference solution.

Use any AI coding assistant that can load the commercetools AI plugin. The commercetools-connect skill covers Connect applications, and the commercetools-integrations skill has a transactional email sub-area for this domain. As in Use the integration guides, ask the assistant which sub-area and step it used.

The requirement

Zen Electron is launching subscriptions for printer ink. Orders created by a Recurring Order schedule emit OrderCreatedFromRecurringOrder instead of OrderCreated. The Connector doesn't subscribe to that type, so customers with a recurring Order get no confirmation.
The email integration guide names this gap in the template: the type must be added to both the Subscription filter and the handler router. After Implement and test the event app to the contract, both read one list, so the change should be small. Whether your assistant notices that is part of the exercise.

A starting prompt:

Using the commercetools-connect skill, add the OrderCreatedFromRecurringOrder
Message type to the mail-sender application in this repository, so that it is
handled as an order confirmation. Keep the existing at-most-once acknowledgment
policy and the least-privilege scopes. Add a unit test. Explain each change.

Acceptance checks

The change is done when every check passes:

  • Filter and router. ORDER_SUBSCRIPTION_MESSAGE_TYPES, or whatever the assistant changed instead, makes both the Subscription filter in src/connector/actions.js and the router in src/validators/message.validators.js include OrderCreatedFromRecurringOrder.
  • Unit test. A test posts an OrderCreatedFromRecurringOrder Message to messageHandler and asserts that the order confirmation handler runs. Adding the type to the routing test's it.each list is enough.
  • Delivery policy unchanged. The controller still returns 202 as its first statement, so the policy recorded in the README still holds. The one-sentence test for the contract gives the same three answers as before.
  • Scopes unchanged. inheritAs.apiClient.scopes still lists manage_subscriptions, view_orders, and view_customers, and nothing else.
  • Validation passes. npm run test:unit and npx eslint src tests pass, and commercetools connect validate reports no findings that your previous release didn't already have. Local SAST can be stricter than the remote gate, so the publishing report for the new tag decides, as described in Trust the remote report.
  • The Subscription has the type after deployment. Move the Deployment to the new version as on Operate a Deployment. Don't skip scripts: postDeploy must run to update the Subscription. Then query the Subscription by key and confirm that messages lists the new type.
  • Reviewed against the docs. You checked each change against the Connect documentation and the email guide, not only the assistant's explanation.
If the assistant changed more than this requirement needs, such as adding handlers for other types, reverting the logging changes from Implement and test the event app to the contract, or adding scopes, reject the change and narrow the prompt.

Record what you used

Add a line to your repository's README with the following:

  • The assistant and model you used.
  • The skill and plugin version, as your plugin manager shows it.
  • The date.

Skills change between versions, and the same prompt can produce different code. The record tells a reviewer what produced the change.

AI assistance doesn't transfer accountability. You own the code that you merge, and you verify it to the same standard as code you wrote yourself.

Verify the result, not the report

An assistant's summary of its own work needs the same rule that applies to a Deployment status: verify the resource, not the report. "I added the type to the Subscription" isn't evidence. The Subscription query in the acceptance checks is.

Key takeaways

  • Give an AI assistant a narrow requirement and fixed acceptance checks, and judge the result by the checks.
  • A new Message type must reach both the Subscription filter and the router. A shared list makes that one change.
  • A change to what postDeploy creates needs a redeploy with scripts enabled, and a query of the resource to prove it.
  • Record the assistant, model, and skill version that produced a change.
  • You remain accountable for AI-generated code. Review it against the documentation, not only against the assistant's explanation.