Check and improve a feature

Use this guide when you have an existing app and want to accept a new feature or improvement. For a first guided exercise, follow Make your first change.

Existing appOne product change

1. Agree on checkable behavior

   Describe the person, action, intended outcome and a case that must be refused. For example:

   Ask your agent

   Let a visitor join a full performance's waiting list once. Offer a released place to the first person in line for one hour. If they do not accept, offer it to the next person. Show whether someone is waiting or has an offer.

   Resolve the product choices needed for the next change with your agent. Can someone decline an offer? Does cancelling a reservation also remove a waiting-list entry? Let the agent record agreed decisions in Progress; you do not need to prepare a detailed implementation plan.

   For new behavior, use the inside-out approach: let the agent establish the rules and behavior tests, connect required integrations, then add APIs and UI. For this example, the tests should cover acceptance, expiry and cancellation. A change to wording or layout can stay focused on that experience while retaining the existing behavior checks.

2. Try the complete flow

   Wait for the agent to confirm the new build is running. Then use App preview to check the successful flow, a boundary and the relevant user roles.

   Check	Example
   Successful action	Make a reservation, refresh and find it again
   Boundary	Accept the last place and refuse an extra reservation
   Repeated action	Repeating the request does not create duplicate work
   Another person	A different visitor cannot change the reservation
   Time or failure	Expiry releases the place; provider failure leaves an understandable state
   Usability	The next action and any error remain clear on a narrow screen

   Use local or provider test data for these checks. A demo response does not verify a live provider account.

3. Inspect the relevant checks

   Ask your agent to map each important rule to a scenario and inspect the managed environment’s latest results. The Dev Server selects affected tests as changes arrive. If a necessary scenario is absent, add it; if the change needs a broader check, agree on that explicitly instead of starting duplicate build/test loops.

   Tests can advance controlled time to check deadlines. Frontend and browser checks may be reported separately from Devboard’s backend scenario list. Ask what was actually checked and whether anything was skipped.

4. Decide whether to accept it

   Compare the observed result with the criteria, including enforcement behind the UI. Hiding an action is not sufficient to prevent an unauthorized request. Use Investigate unexpected behavior for discrepancies.

   Once accepted, save a code checkpoint and record the outcome and known gaps in Progress. A Git commit preserves source changes; it does not reverse stored data or external side effects. Follow Publish an update when the checked change is ready for users.

   Ready to publish

   The changed flow works, the important rules have checks, and the reviewed version is saved.