How to Build and Deploy a REST API with AI on Adios

Help me plan a production-shaped REST API in this Adios workspace. Do not edit files yet.

The API:
- Name: [API NAME]
- Consumer: [WEB APP, MOBILE APP, INTERNAL TOOL, OR PARTNER]
- Core resource: [RESOURCE]
- Main actions: [CREATE, LIST, READ, UPDATE, OR OTHER ACTIONS]
- Authentication: [NONE FOR A PUBLIC DEMO, USER TOKEN, OR SERVICE API KEY]
- Database: [CURRENT PROJECT DATABASE OR POSTGRES]

Before proposing changes, inspect the repository, current framework, package manager, tests, health route, environment configuration, and adios.yaml.

Return:
1. the route table with methods and response codes;
2. request and response shapes;
3. validation and error behavior;
4. the data model and migration approach;
5. authentication and authorization boundaries;
6. rate-limit or abuse considerations;
7. automated tests and manual curl examples; and
8. the Adios runtime, health, database, and secret configuration required.

Prefer the existing stack. Explain any new dependency. Wait for my approval before editing.

Build the REST API from the plan I approved.

Requirements:
- Keep the existing language, framework, package manager, and Adios deployment files.
- Preserve a lightweight unauthenticated health endpoint that does not expose private data.
- Validate every external input and return one consistent JSON error shape.
- Enforce authentication and authorization on the server when the plan requires them.
- Use parameterized database access through the project's established data layer.
- Add reversible migrations if this repository uses migrations.
- Never hard-code credentials. Refer to database and authentication values by environment-variable name.
- Add concise API documentation and runnable example requests.
- Add tests for the happy path, invalid input, missing records, unauthorized access, and one database failure path that can be tested safely.
- Run the formatter, linter, tests, and production build or compile command already used by the project.

When finished, give me the route table, changed files, test results, required Adios configuration, and exact commands I can run against Preview. Do not deploy to production.

Review this API as if an unknown client will call it. Fix only verified issues and do not deploy.

Check:
- routes use the intended HTTP methods and status codes;
- malformed, missing, oversized, and unexpected inputs fail safely;
- authentication cannot be bypassed and one caller cannot access another caller's protected data;
- error responses do not expose stack traces, secrets, database details, or internal paths;
- repeated requests behave safely where idempotency is required;
- database writes and migrations are consistent;
- API documentation and example requests match the implementation;
- health checks remain lightweight;
- logs are useful without recording credentials or sensitive request bodies; and
- all formatter, lint, test, and compile or build checks pass.

Return a table of checks and evidence, the exact Preview requests I should run, and any remaining risk.

Prepare this API for an Adios deployment review. Do not deploy until I approve it.

Confirm the start command, listening host and port, health path, required environment-variable names, database dependency, migration command, and expected public route. Compare them with adios.yaml and report any mismatch.

Then give me:
1. the final automated-check results;
2. five safe smoke-test requests for the Preview URL;
3. one rollback or recovery note for a failed migration;
4. the secrets I must configure through Adios rather than source; and
5. a post-deployment check covering health, logs, authentication, and one write/read cycle.

Stop for my approval before production deployment.