Guide navigation 3 of 42
What this page helps you accomplish
Follow the current 11-step Batoi Build App Lifecycle from app record through verified deployment, evidence, Guard review, and member-safe sharing.
Scope and authority
Access to the intended authenticated workspace through My Batoi Authority to review the selected project, app, repository, sandbox, database, release, and sharing records
Guided Lifecycle
Follow the current 11-step Batoi Build App Lifecycle from app record through verified deployment, evidence, Guard review, and member-safe sharing.
Observable business result
The app has verified setup, deployment, assurance, evidence, and member-sharing outcomes rather than lifecycle badges alone.
The expected record or action is missing.
Recommended recovery: Return to the intended context and ask an Owner or Admin to confirm access. Do not use another person’s account.Who should use this article
This article is for Workspace Owners, Workspace Admins, Builders, and Release Owners who are authorized to complete or review this task. A consequential decision remains with the accountable person.
Before you begin
- Access to the intended authenticated workspace through My Batoi
- Authority to review the selected project, app, repository, sandbox, database, release, and sharing records
- Use approved sample or operational information only. Never enter a password, token, private key, or unnecessary personal information.
Open the App Lifecycle
- Enter the authorized workspace through My Batoi.
- Open Build, choose Applications, and select the intended app.
- Under Overview, open Lifecycle.
- Confirm that the workspace, project, app, and owner shown in the selected-app context are correct.
Complete the lifecycle in four phases
1. Establish the app context
- App Record: confirm the app name, stable key, build mode, app type, runtime, owner, and Active status.
- Project Binding: verify the app belongs to the intended Core Project and does not show fallback records from another project.
- GitHub Repository: link the canonical repository and default branch, then assign repository synchronization and pipeline ownership.
2. Connect the sandbox runtime
- Sandbox Target: register a non-production target and verify that its source and credential boundary are correct.
- Database MCP: connect the app-scoped development database and approve the intended MCP profile without exposing connection secrets.
- Baseline Build: place the foundational app in the repository, apply the approved schema and seed data, and verify the homepage and health route.
3. Publish, verify, and preserve evidence
- Publish Run: publish an explicit reviewed revision to the sandbox and require a persisted run manifest.
- Deployment Verification: confirm the deployment reached a terminal status and independently check the homepage, health route, and data adapter result.
- Guard Gate: run the release-specific Guard evaluation; an Active gate is not the same as a Passed evaluation.
- Govern Evidence: record the source, review, publish, deployment, Guard, and approval outcome with an accountable owner.
4. Share only an approved member view
- Member-Safe Sharing: create a project-sharing policy with an explicit recipient, audience, redaction level, visible sections, and approval state. Test the permitted member view before handoff.
Use honest completion criteria
| Lifecycle area | Do not stop at | Verify instead |
|---|---|---|
| Repository | Linked badge | Correct repository and branch, synchronization configured, and pipeline owner assigned. |
| Publish | Run created | Terminal status, exact revision and target, and persisted publish-run manifest. |
| Deployment | Deployment row exists | Succeeded status plus independent homepage, health, and adapter checks. |
| Guard | Gate is Active | Release-specific evaluation passed or an authorized, time-bounded exception exists. |
| Evidence | Evidence record exists | Evidence is reviewable, linked to the release outcome, and accepted where required. |
| Sharing | Sharing control is available | The intended project policy is Ready or Approved and the member portal shows only permitted content. |
Continue with focused articles
- Create an Application Workspace in Batoi Build
- Connect a Source Repository to Batoi Build
- Prepare a Sandbox Environment in Batoi Build
- Connect an Application Database in Batoi Build
- Configure and Apply a Security Policy Gate in Guard
- Prepare an Evidence Plan in Batoi Govern
- Publish and Verify an Application Release in Build
- Configure Member-Safe Project Sharing
Troubleshooting and recovery
| What you see | What to check | Safe next action |
|---|---|---|
| The expected record or action is missing. | Workspace, project/app context, role, status filters, and prerequisites. | Return to the intended context and ask an Owner or Admin to confirm access. Do not use another person’s account. |
| The status remains incomplete or needs review. | Required fields, evidence, approvals, source connections, checks, and owners. | Record the missing item and owner. Do not mark the task complete until it can be independently verified. |
| The result conflicts with policy or evidence. | Scope, source recency, exception authority, decision conditions, and reviewer independence. | Do not bypass the control. Return the item for correction or escalate it through the authorized route. |
Safety and governance
Final verification
Next step
Continue with the next verified article in this Product Guide, or return to the Batoi Platform Product Guide.