An unfinished Replit Agent app can look further along than it is. A task marked Done may be archived or cancelled, while a working preview may cover only one route. This guide starts in an app you already own. You will compare its original requirements with the files and behavior now present, finish one existing user journey, then check a first restricted release. The examples below are fields to fill from your project; BIG CHANGE has not run your app or verified a release.
The big change
- What changed: Replit's Plan mode, task board and checkpoints give an app owner a way to inspect earlier Agent work and direct a bounded repair within the existing project. The board's status alone does not establish that a requirement works.
- Why it matters: You can tie each original requirement in one journey to a changed file and an observed result before approving the release. That keeps unfinished or cancelled work visible when deciding what is ready.
- What to watch: Publishing includes every artifact in the project. The release decision therefore covers the whole artifact list, production data and audience, even when the repair concerns only one web journey.
Decide what this release must do
You need edit and Publishing rights to the existing Replit project, permission to use its code, assets and data, approved test identities, and authority to approve the audience and spend. Open the actual project in the Project Editor. Record its URL, framework, routes, data source, current live status, available tests and last known good checkpoint. Do not put secret values in this record. Check the account's Agent mode and Usage before asking Agent to work. Plan mode is available in an app's Project Editor; its availability and charges depend on the account and mode. Replit's AI billing guide distinguishes Free Mode allowance from paid work, including billable planning. Check actual usage again after work because reporting may lag.
Choose one journey the original project was meant to support, using this fill-in record:
Record | Fill from your app |
|---|---|
Authorized actor and actual start route | |
Permitted input and expected response | |
Result that must survive a reload or fresh request | |
Denied or error case on the same path | |
Scope ceiling | |
Intended first audience | |
Set a stop list before work starts. An extra screen, integration, payment flow or infrastructure change needs its own reason and approval. If the original requirement, legal right to use the data, or intended audience is unclear, resolve it before building or publishing. An app already serving live users or real data needs a separate update and migration plan; this first-release path does not cover that transition.
1. Reconstruct the actual baseline
In the Project Editor, inspect the preview, files, run and test commands, recent checkpoints and Agent task board. Read Drafts, Active, Ready and Done, including each task's plan, work log and diff. Replit says Ready work is isolated until you apply it. Done can also contain archived planning sessions and cancelled tasks. Check the implementation and preview instead of treating a column as proof.
Inventory every project artifact: the web app and any mobile app, slide, video, design, data visualization or other output sharing this project. For each, note the data it exposes, who should see it, and whether it belongs in the first release. Replit's Agent overview says all artifacts publish together. Save the baseline file revision or checkpoint, current preview results, relevant logs and permitted screenshots. Record exact failing route and response; mark anything you have not tried as untested.
Use the original plan and task history to make a requirement ledger before trimming the work to one journey. One row should read like this, with your own real values:
Original requirement and task state | Current implementation and changed files/checkpoint | In selected journey? | Expected check | Observed result and revision |
|---|---|---|---|---|
| | | | |
Create a row for each original requirement, including cancelled or archived work. Keep deferred items visible with an owner decision. Every requirement included in the chosen journey must have a real implementation and observed check before you call it complete.
2. Plan the smallest repair in this project
Select Plan in the existing project's Agent input. Give Agent the baseline, the requirement ledger, one journey, denied case and stop list. Ask for an ordered repair plan that identifies files and any proposed database, secret or hosting change. Replit's Plan guide says planning precedes code or data changes; approving Build here or Build in background starts implementation. Review and revise the plan before approval. Reject a proposed new app, stack replacement or unrelated feature unless your observed failure and owner approval justify it.
Use my existing unfinished project [PROJECT URL]. First inspect its actual files, preview, original requirements, task board and recent checkpoints. Baseline revision: [REVISION]. Observed behavior and exact failing route/response: [RESULTS].
Finish only this original journey: [ACTOR, ROUTE, PERMITTED INPUT, EXPECTED RESPONSE, PERSISTENCE CHECK]. Denied/error case: [ACTOR OR INPUT AND EXPECTED RESPONSE]. Reconcile each included original requirement to the current implementation, changed files and an observable acceptance check. Mark missing or untested work explicitly. Stop list: [EXCLUSIONS].
Propose the smallest ordered repairs in this project. Flag any schema, data, secret or infrastructure change for my review. Show the diff and checkpoint, run this project's actual build/tests, and check the journey in preview. Report exact results and remaining failures. Stop before Publish or production data changes.The task-board menu offers Auto-approve plan and Auto-apply changes as one-shot actions. Leave those actions unused for this reviewed path. Plan mode has a separate background-build Automatically apply changes option; leave it unselected. Verify the actual task options before starting, as the two controls have different scopes.
3. Build, inspect and test the journey
Approve the revised plan, then follow each task's actual state. For a Ready task, open its work log, test output, preview and diff. Select Apply changes only after accepting that exact work. In the current session, inspect the checkpoint and changed files after implementation. Run the project's actual build and tests. Exercise the chosen journey in preview with permitted test data, then reload or make a fresh request to check persistence. Test the denied case by requesting the relevant route or operation directly when appropriate; a hidden button cannot establish server denial.
Return to the requirement ledger. Fill in the changed files/checkpoint and actual pass, fail or untested observation for every included row. A passed build or Agent's own summary cannot stand in for those observations. Give Agent the exact failure and ask for a bounded repair. Review its next diff and repeat every check the change affects. Stop if any included original requirement remains missing, failed or untested.
If a task's result or Apply response is uncertain, read the task board, files, diff and preview before trying again. For a rollback, inspect what changed after the selected checkpoint. Replit's checkpoint guide says rollback restores files and Agent context; restoring the development database is optional and off by default. Production restoration is a separate decision. Preserve later good work and check files, preview and data after any restore. Do not assume Agent remembers work that the rollback removed from its context.
4. Review everything the first release would expose
Open Tools → Replit Cloud → Publishing and inspect domain, What you're publishing, Sharing, hosting, security controls and production database settings. Compare the current entire artifact list with the baseline inventory. For each artifact, inspect its visible output, connected data and approved audience. The owner approves the exact whole-project revision, not just the repaired web route. If an unwanted artifact appears, remove or revise it through a reviewed source/artifact diff, read back the inventory and preview, then repeat affected checks. Hold the release if an artifact cannot be inspected or approved.
Check which database path this project actually uses. Replit's database guide separates development from production. On current Helium infrastructure, it says a production database is created on publish when the development database contains data. On legacy Neon projects, you choose Create production database in publish settings and can separately opt to copy development data. Review schema changes that will apply at publish, data-copy selections, seed/test records and the expected production readback. Keep unapproved private or test data out of production. Check the destination and names, never values, of secrets that Publishing will sync or require.
Choose a restricted option such as Invite only when available and appropriate, then inspect the full audience, including workspace admins and invited people or groups. Replit's access guide says a personal project's default is Public and that workspace admins have access under Invite only. Host access and the app's own authorization rules protect different boundaries; test both. Changing host access later requires unpublishing and republishing. Confirm the actual domain, release revision, artifact list, data action, audience and estimated spend with the project owner before selecting Publish. Replit documents usage-based hosting and production database charges; the actual amount depends on this app and account.
5. Check the live URL before declaring completion
Record the live URL, publish time and revision returned by Publishing. As an allowed viewer, repeat the same journey using permitted data and verify its persistent or exported result after reload or a fresh request. As a signed-out or excluded viewer, check the relevant host and app routes, including the operation behind the UI. Inspect logs, errors and production data readback for the actual result. Write the allowed and denied observations beside the same acceptance rows used in preview.
If a live gate fails, record the exact URL, revision and response. Restrict exposure using the owner's controls if necessary, repair the observed failure in development, review the new whole-project release and rerun affected live checks. If Publish returns an uncertain response, inspect Publishing state and the live URL before attempting another publish.
Keep the baseline, original-requirement ledger, accepted diffs and checkpoints, tests, preview and live observations, full artifact inventory, data and secret-name review, audience approval, actual usage and unresolved items in a private release record. The first release is complete only when the chosen journey and denied case pass at the approved live revision and the owner has approved every artifact and data surface it publishes.
For readers building a new project instead, our feedback-board guide and real-data dashboard guide cover distinct Replit Agent tasks.
Sources & further reading
- Replit Plan mode: how to plan within an existing app, review a task list and approve a build. Its billing sentence should be read alongside the current billing guide's Free Mode distinction.
- Replit task board: Drafts, Active, Ready and Done, review/apply actions and the one-shot task-menu controls. Done can include archived or cancelled tasks.
- Replit Agent overview: project artifacts and the rule that they publish together.
- Replit checkpoints and rollbacks: file and Agent-context restoration, optional development data restoration and separate production recovery.
- Replit Publishing and app access: the publishing pane, audience choices and the unpublish/republish step when live access changes.
- Replit development and production databases: separate data stores, current Helium and legacy Neon setup, and publish-time schema/data decisions.
- Replit effective prompting and AI billing: incremental requests, exact error context, account-dependent allowances and paid usage.
These unversioned English Replit manuals were checked on 22 October 2026. Their controls and prices can change; inspect your project's current account and Publishing pane. This is a documentation-based workflow, not a report of a Replit account, app, database or deployment test by BIG CHANGE.
