Build a publication checklist app with AI

Define the review screen's boundary

Start with a team preparing three articles for release. Manage candidates, assigned checks and reasons for returning a draft. Do not connect every CMS to automated publishing in the first version. Identify an approved candidate version before adding execution. Name the editor, reviewer and publisher roles in the agent brief. A person may perform several roles, but a decision should still record which responsibility they were exercising.

Separate articles from release candidates

Give each release candidate its own identifier and version, linked to the article ID. Preserve enough information to identify the title, body, image references and URL that were reviewed. A check records its candidate version, assignee, outcome, time and evidence. Bolt's database or Supabase integration can store these records, but verify the existing connection before changing it. A corrected review decision should not erase the earlier explanation.

• Review Bolt publishing and storage

Write observable acceptance criteria

Replace a vague quality check with observable conditions: a stated price matches its cited terms, the intended image loads, or a related link reaches the correct page. Distinguish automated checks from editorial decisions. Evidence may be a URL, section reference or revision request. When requirements change, show newly added checks as pending rather than inheriting an old completion count that makes the revised checklist appear fully reviewed.

Invalidate decisions when content changes

Create a new candidate version after a reviewed body or image changes. Define explicitly which checks can carry forward; do not copy every checked box without evidence. For a small first release, repeating review after content changes may be simpler to audit than automatic fine-grained impact analysis. The server must compare the expected candidate version and status when accepting a decision, preventing an old browser page from approving a candidate already returned by another reviewer.

• Prepare a reviewable handoff

Rehearse a three-article release

Prepare article A with all required checks complete, B with an image check pending and C awaiting a link correction. Only A should appear ready, while B and C explain their blockers and owners. Then revise A's body and verify that its new candidate is not approved merely because the old one passed. Include duplicate clicks and interrupted responses. These are acceptance scenarios to perform after implementation, not reported Bolt test results.

Attach a release record to the candidate

Record the candidate, version, destination URL, execution time and outcome when the publisher acts. A later CMS integration may also retain the external publication identifier. Sending a request is different from verifying its result; an uncertain response is not proof of success. Reconcile the published title, images and body version with the candidate. Use an operation identifier so a repeated request does not create a second article.

Estimate versions and evidence storage

Separate Bolt building usage from the deployed review app's database, evidence files and notifications. Count candidate versions, review activity and retention rather than article count alone. Keeping full snapshots consumes different storage from retaining references to independently versioned content. Begin with a few articles and essential checks before adding channels or scheduling. Even if history is pruned, preserve enough information to explain which version was released, and verify current provider billing terms.

• Define role-specific permissions

Distinguish stopping from restoring

If a serious problem appears, pause new releases and list affected candidates and live pages. Withdrawal or rollback depends on the publishing destination; changing the review app's status alone does not repair the live page. Record any restoration as another release event with its own result. At handover, transfer pending checks, return reasons and candidate-to-publication mappings. Give editors, reviewers and publishers the permissions required for their operations, rather than one unrestricted role.