Guide contents
A first deploy only shows that the service starts. What matters next is that the app keeps its data and survives updates. Let's ask the agent for a small requests API with Postgres and check it in two states: before the change and after.
What to prepare
- You need access to Octo Cloud and the ability to create a Postgres database in your workspace. Ask the agent about resource terms before you start.
- Download the practice brief. It defines the request fields, the create and read operations, and a small change for the second deploy.
- Use a separate practice service with test data for this exercise. Say who is allowed to send requests to it.
The source files use sample data. Replace it with your own once you know the process.
Lock down the service contract
Ask the agent to build the API and connect Postgres. In the brief, list the fields, which are required, the responses to valid and invalid requests, and the access rules.
Connection settings should live in the service configuration. Ask the agent to show which parameters are needed without printing secret values into public code or examples.
Deploy a practice requests API with Postgres on Octo Cloud, following the attached brief. Confirm the resource terms and the access you need. Keep secrets in configuration outside public code. Implement creating and reading a request with input and access validation. Give me the service address and example requests without secret values.
Write and read back test data
Create a request, save its ID and read the record back with a separate request. This checks more than a successful API response: it confirms you can get the data again.
Check an invalid email and a request without the required access. The responses should match the agreed contract. Do not accept the agent saying "all done" in place of a check.
Update the service and keep the record
Add an optional "comment" field. Ask the agent to change the schema and the service so that existing records are kept.
After the redeploy, read the old request by its saved ID and create a new one with a comment. If the old record cannot be retrieved, the update is not complete.
Add an optional comment field and update the practice service. Keep the existing data. Before the change, describe how to recover if it fails. After the update, read the old request by its saved ID, then create and read a new one with a comment. Show the actual results of the checks.
Example result
What to compare before and after the update
- Before: the API creates a request with a name and email, returns an ID and reads the record by it.
- After: the same record is available under the same ID; a new record also stores a comment.
- Without the required access the request is rejected. The connection secret does not appear in page code or example text.
The key catch and the check
A working API does not prove that data survives the next change. The update check must include the old record. For a production service, agree separately on backups, recovery and operations, given the hosting options available.
Before you use the result
- Creating and separately reading a record return consistent data.
- Invalid input and requests without access are handled according to the contract.
- After the update, the old record is still there.
- The new record supports the added field; secrets are not exposed.
How to repeat this on your own task
Keep the brief, the check commands and the update rules next to the project. For later changes, ask the agent not only for new code but also to rerun the scenarios your users already rely on.
Try this scenario
Download the source file, copy the task and send it to the agent together with the file.