Delivery workflow · illustrative example
Supernova connects project documents, client conversations, and delivery plans in one workspace. This fictional online-store example shows what AI agents draft, what people review, and how an agreed requirement becomes working software.
The fictional client request
“A returning buyer can reorder in one tap.”
The team agrees that one tap fills the cart. The buyer reviews changes before placing an order. Follow the request through nine steps to see the specifications, prototype, tasks, and checks.
Scroll to follow the nine steps
The client asks for one-tap reordering. Supernova keeps that sentence with its source and identifies questions: does the tap place an order or fill a cart? What happens to unavailable items?
Output: the source request and questions to resolve.
The project owner clarifies what the client expects before the team plans the feature.
For this example, one tap adds available items from a previous order to the cart. The buyer reviews unavailable items and the delivery address before placing the order. If nothing is available, the cart stays unchanged and the buyer sees why.
Output: a use case describing the normal and exception paths.
The Tech Lead, the senior engineer responsible for the build, reviews the agreed behavior.
Supernova drafts a data model: the records the feature needs and how they connect. A previous order contains products. A cart contains currently available items. The specification defines how stock and delivery addresses are checked.
Output: entities, fields, and relationships.
The Tech Lead checks that the data model supports the agreed behavior.
The buyer can reorder from their own purchase history. Support can investigate a failed attempt. Operations manages stock. Supernova records these permissions alongside the actions each role needs.
Output: roles and permitted actions.
The project owner reviews access requirements before developers implement them.
A designer defines the typography, buttons, layouts, and error messages. The reorder action uses those rules, including a clear explanation when some items cannot be added.
Output: reusable design rules.
The designer reviews a consistent starting point for the screens.
Supernova maps order history, cart review, and checkout to the use-case steps. Each screen specification lists the data shown, available actions, and loading, empty, and error states.
Output: screen specifications and a flow diagram.
The team checks that the specifications cover the complete buyer journey.
The prototype builder turns the screen specifications into an interactive preview at phone and desktop sizes. The client can try the reorder flow and give feedback before the production feature is implemented.
Output: a clickable prototype for review.
The client and designer review the interaction; developers still need to build the production feature.
Supernova drafts developer tasks and acceptance criteria from the reviewed specifications. The reorder task points to the use case, screen, and data model. The Tech Lead reviews the plan, then the assigned developer implements the feature.
Output: reviewed tasks, followed by working code.
The developer can trace the task back to the client's request and agreed decisions.
Test agents write browser tests from the acceptance criteria and run them against the implemented feature. The reorder test checks which items reach the cart and confirms that the tap does not place an order. The team reviews failures and remaining coverage gaps.
Output: test results for the implemented feature.
A test result supports the release decision. The responsible people decide whether the feature is ready.
The fictional client request
“A returning buyer can reorder in one tap.”
One tap fills the cart. The buyer reviews changes before placing an order.
The client asks for one-tap reordering. Supernova keeps that sentence with its source and identifies questions: does the tap place an order or fill a cart? What happens to unavailable items?
Output: the source request and questions to resolve.
The project owner clarifies what the client expects before the team plans the feature.
For this example, one tap adds available items from a previous order to the cart. The buyer reviews unavailable items and the delivery address before placing the order. If nothing is available, the cart stays unchanged and the buyer sees why.
Output: a use case describing the normal and exception paths.
The Tech Lead, the senior engineer responsible for the build, reviews the agreed behavior.
Supernova drafts a data model: the records the feature needs and how they connect. A previous order contains products. A cart contains currently available items. The specification defines how stock and delivery addresses are checked.
Output: entities, fields, and relationships.
The Tech Lead checks that the data model supports the agreed behavior.
The buyer can reorder from their own purchase history. Support can investigate a failed attempt. Operations manages stock. Supernova records these permissions alongside the actions each role needs.
Output: roles and permitted actions.
The project owner reviews access requirements before developers implement them.
A designer defines the typography, buttons, layouts, and error messages. The reorder action uses those rules, including a clear explanation when some items cannot be added.
Output: reusable design rules.
The designer reviews a consistent starting point for the screens.
Supernova maps order history, cart review, and checkout to the use-case steps. Each screen specification lists the data shown, available actions, and loading, empty, and error states.
Output: screen specifications and a flow diagram.
The team checks that the specifications cover the complete buyer journey.
The prototype builder turns the screen specifications into an interactive preview at phone and desktop sizes. The client can try the reorder flow and give feedback before the production feature is implemented.
Output: a clickable prototype for review.
The client and designer review the interaction; developers still need to build the production feature.
Supernova drafts developer tasks and acceptance criteria from the reviewed specifications. The reorder task points to the use case, screen, and data model. The Tech Lead reviews the plan, then the assigned developer implements the feature.
Output: reviewed tasks, followed by working code.
The developer can trace the task back to the client's request and agreed decisions.
Test agents write browser tests from the acceptance criteria and run them against the implemented feature. The reorder test checks which items reach the cart and confirms that the tap does not place an order. The team reviews failures and remaining coverage gaps.
Output: test results for the implemented feature.
A test result supports the release decision. The responsible people decide whether the feature is ready.
An inspectable example
These sample records show the agreed outcome of the walkthrough. They are illustrative specifications, not results from a real project or a test run.
Review outcome: “one tap” means adding items to a cart. Checkout remains a separate decision. The test must also cover an empty result, a changed address, and a stock change before checkout.
Give the team a requirement they can build and check.