Feedback: tell us what is missing
If you build for an iVendNext customer and find something missing or broken, four forms are how you tell us.
Open a form
| Form | Use it when |
|---|---|
| Kit defect | a piece of the kit does not do what its recipe says |
| Point request | no rung of the ladder can meet a need, or a published extension point is missing something |
| Recipe or document gap | a guide chapter, recipe or reference page is missing, wrong or unclear |
| Sample request | you want a worked example of a pattern we do not show yet |
Each form opens on GitHub and needs a GitHub account. The forms are public, so never put a secret in one (no key, password, signing secret or token) and no shoppers' personal data.
Which form for what
| Form | Use it when | Not this form if… |
|---|---|---|
| Point request | Your blueprint has a need that no rung of the ladder can meet, or a published extension point is missing something you need. | A recipe or page is wrong or unclear → recipe or document gap. Something that should work does not → kit defect. |
| Recipe or document gap | A guide chapter, recipe or reference page is missing, wrong, out of date, unclear or has a broken link. | The page is right but the kit behaves differently → kit defect. |
| Sample request | You want a worked example of a pattern we do not show yet, or a variant of one we do. | You want a new way in, not an example of an existing one → point request. |
| Kit defect | A piece of the kit does not do what its recipe says: event feed client, manifest, Wasm kit, MCP server, design kit, sign-in recipe, scale-profile kit. | The kit does what it says but you want it to do more → point request or sample request. |
Not sure? Ask in this order:
- Did something that the page says should work fail? → kit defect.
- Is the page itself wrong, missing or confusing? → recipe or document gap.
- Do you only need to see the pattern done once? → sample request.
- Does the ladder have no door for the need, even after the blueprint? → point request.
If one problem fits two forms, send the one that names the cause. If you send two, say so in each.
Before you fill one in
- Do the blueprint first (
../kit/blueprint.md). A point request without a placed need is hard to answer, and most needs turn out to be configuration, an outside app or a manifest. - One subject per form. Two needs mean two forms.
- Never put a secret in a form. No API key or secret, no password, no signing secret, no token. Black them out of any log you paste.
- No shoppers' personal data. Use made-up customers and made-up sales. Describe your own customer in general terms ("a forty-store pharmacy chain") unless the customer has agreed to be named.
- Name the place you tried it: your sandbox site, or the customer's staging site. Say so if you saw it only on a live customer's site.
What a form is not
- Not a support request for a customer's live site. Support is not decided yet; guide chapter 17 says what is open.
- Not a licence or price question.
- Not a way to ask us to set aside one of the four rules: a total changed after the cashier has seen it, overrides or patches, outside code inside a customer's site, your JavaScript inside Desk or the till. Those are closed by design. A request that needs one of them is read as a request for an extension point that meets the need another way.
The forms in full, with a hint and an example for every field, are in the feedback pages.