Release Readiness Checklist¶

Document status: Release governance template. This document does not certify any release or imply that the listed checks have been executed.

Use this checklist to evaluate whether a WhiteLotusAI release candidate is ready for deployment. Each mandatory acceptance criterion must be supported by appropriate evidence, and unresolved risks must be explicitly reviewed before a release decision is recorded.

1. Release overview¶

Objectives¶

• Verify source integrity, build reproducibility, and automated test results.
• Validate authentication, authorization, data isolation, and secret handling.
• Confirm integration behavior and enforce the approved read-only policy where required.
• Review database, deployment, recovery, and operational readiness.
• Record defects, exceptions, approvals, and supporting evidence.

Release lifecycle¶

flowchart TD
    A["Identify release candidate"] --> B["Validate source, build and tests"]
    B --> C["Review configuration and security"]
    C --> D["Verify integrations and data handling"]
    D --> E["Validate deployment and recovery"]
    E --> F{"Mandatory checks satisfied?"}
    G --> B
    F -- "Yes" --> H["Review defects, risks and evidence"]
    F -- "No" --> G["Block release and assign corrective actions"]
    H --> I{"Authorized release decision"}
    I -- "Ready" --> J["Approve deployment"]
    I -- "Exception approved" --> K["Record authorized exceptions"]
    K --> J
    I -- "Blocked" --> G

    classDef process fill:#e8eef8,stroke:#496b9a,color:#172b4d,stroke-width:1px
    classDef decision fill:#fff0cf,stroke:#a97920,color:#593b08,stroke-width:1px
    classDef blocked fill:#fbe5e5,stroke:#b94a48,color:#6e2020,stroke-width:1px
    classDef approved fill:#dff3e8,stroke:#318568,color:#164b3a,stroke-width:1px

    class A,B,C,D,E,H process
    class F,I decision
    class G blocked
    class J,K approved

The diagram describes the intended governance process, not an automated release pipeline. Mermaid colors are explicitly assigned for readability in supported light and dark themes.

2. Release record¶

Complete the release record before beginning the final acceptance review.

3. Acceptance status and evidence¶

Use consistent statuses throughout the release review.

For repeatable execution, maintain the checklist results in the team's approved issue tracker, release record, or test-management system. This Markdown document defines the requirements; it is not itself an execution log.

4. Source, build, and test validation¶

• The intended source revision has been identified and reviewed.
• Required dependencies, runtime versions, and build tools have been verified.
• The application builds successfully using the documented process.
• Required automated tests have executed in the intended test environment.
• Failed, skipped, flaky, and blocked tests have been recorded and assessed.
• No test is reported as passing without execution evidence.
• Build artifacts correspond to the reviewed source revision.
• Dependency and container-image scanning requirements have been satisfied.
• The release does not rely on undocumented local configuration.
• Required CI quality gates have passed.

Suggested validation commands¶

Run the commands appropriate to the repository and target environment. These are examples, not a claim that they have been executed.

uv run zensical build --clean --strict

uv run pytest

npm ci
npm run lint
npm run build

5. Configuration and secrets¶

• Required environment variables and their purposes are documented.
• Target-environment configuration is present and validated.
• Missing or malformed configuration causes controlled failures.
• Production credentials are absent from committed source files.
• OAuth client secrets, refresh tokens, API tokens, and signing keys use the approved secret-management process.
• Exposed credentials have been assessed, revoked or rotated where necessary, and investigated.
• Development-only credentials and debug settings are disabled where inappropriate.
• Service endpoints, callback URLs, authentication settings, and allowed origins match the target environment.
• Sensitive values are not exposed through startup messages, exception traces, or diagnostic endpoints.
• Configuration changes have been reviewed and their impact assessed.

6. Security and access control¶

• Authentication is enforced on protected endpoints.
• Authorization is checked server-side for each protected operation.
• User-specific records and provider connections remain isolated between accounts.
• Internal service requests require the intended authentication and authorization controls.
• Sensitive information is excluded from logs and client-facing error responses.
• OAuth callbacks validate the expected state and applicable security parameters.
• Token refresh, expiry, revocation, and failure scenarios have been tested.
• Rate limits and request bounds are configured where required.
• Security findings have documented severity, ownership, and disposition.
• No unresolved critical security issue remains without explicit authorization and a documented risk assessment.

7. Integration readiness¶

Review each integration independently. Update the table using actual test evidence rather than the presence of an implementation or a successful connection indicator.

For every applicable integration:

• OAuth or other approved authentication completes successfully.
• Missing, expired, revoked, and insufficiently scoped credentials are handled safely.
• Read operations return only data authorized for the requesting user.
• Provider errors, rate limits, and throttling are handled predictably.
• External requests use appropriate timeouts and bounded result sizes.
• Pagination and partial-result behavior have been tested where applicable.
• Write-capable operations are blocked when strict read-only behavior is required.
• Direct API routes cannot bypass the approved policy.
• Negative tests demonstrate rejection of disallowed operations.
• End-to-end test results identify the release candidate and target environment.

8. Read-only policy acceptance¶

For releases that require strict read-only access, treat this section as a mandatory security gate.

• Every registered tool and its effective permissions have been inventoried.
• Every reachable write-capable API route has been identified.
• Server-side policy enforcement rejects prohibited operations before provider execution.
• User confirmation, model-generated arguments, and client-side controls cannot override the policy.
• Legacy handlers, alternate routes, and indirect dispatch paths have been reviewed.
• OAuth scopes are limited to the approved access requirements where provider capabilities permit.
• Shared-token fallback paths cannot expose data across users.
• Negative tests cover direct API requests, tool dispatch, and relevant alternate paths.
• Test evidence confirms blocked operations do not reach the external provider.
• Policy tests were executed against the intended release candidate.

9. API and service validation¶

• API documentation matches the routes registered by the release candidate.
• Authentication, authorization, and internal-service requirements are documented.
• Request and response schemas have been reviewed.
• Error responses match the documented API contract.
• Request sizes, result counts, pagination, and other bounds have been verified.
• Outbound calls use appropriate connection and response timeouts.
• Health and readiness checks report meaningful conditions.
• Dependency failures and service startup order have been assessed.
• Retry behavior does not introduce unsafe duplicate operations.
• API compatibility and required migrations have been assessed.

10. Database and data handling¶

• Database connectivity and required permissions have been verified.
• Schema changes and migration prerequisites are documented.
• Migrations have been tested in an appropriate non-production environment.
• Backup coverage and restoration procedures are understood and verified where required.
• User-owned data access and tenant isolation have been tested.
• Retention and deletion behavior are documented where applicable.
• Sensitive production data is excluded from test fixtures and diagnostic logs.
• Data migrations are compatible with the planned deployment and rollback strategy.
• Database capacity and relevant query-performance risks have been reviewed.

11. Deployment and operational readiness¶

• Deployment instructions are reproducible and match the intended environment.
• Required services, databases, queues, caches, and external dependencies are available.
• Startup, health-check, and readiness behavior have been tested.
• Logs and diagnostic signals are accessible to authorized operators.
• Resource limits, timeout settings, and provider failure behavior have been reviewed.
• Monitoring and alerting cover critical failure conditions where required.
• Rollback or recovery procedures are documented and appropriate for the change.
• The deployed version and artifact can be identified unambiguously.
• Operational ownership and escalation procedures are established.
• Post-deployment smoke tests and acceptance criteria are defined.

Deployment and recovery review¶

12. Documentation validation¶

• Navigation links point to existing documentation pages.
• The documentation build passes the configured strict validation.
• Configuration documentation reflects the current implementation.
• API documentation matches registered routes and schemas.
• Integration documentation distinguishes implemented functionality from verified behavior.
• Known issues and open findings remain documented until resolved and verified.
• Test claims reflect actual execution evidence.
• Release-specific instructions have been reviewed.
• Diagrams and architecture descriptions reflect the verified or explicitly qualified system design.
• Documentation changes have been reviewed alongside relevant implementation changes.

13. Defect and risk review¶

For each unresolved issue that could affect the release, record the following information in the approved tracking system.

Documentation changes alone do not resolve implementation defects or security findings.

14. Final release decision¶

Choose one decision after reviewing all mandatory checks, evidence, and unresolved risks.

The release owner must record the final decision, reviewer identities, decision date, source revision, evidence links, and any approved exceptions in the designated release record.

15. Post-deployment verification¶

After deployment, perform the checks required by the release plan.

• Confirm the deployed version matches the approved release candidate.
• Verify application startup and readiness.
• Execute the defined smoke tests against the deployed environment.
• Confirm authentication, authorization, and critical user workflows.
• Verify integration connectivity and applicable read-only enforcement.
• Review error logs, service health, and relevant alerts.
• Record deviations and initiate rollback or recovery when acceptance criteria are not met.
• Document the deployment outcome and assign follow-up actions.

Post-deployment verification does not replace pre-release approval.

16. Release review summary¶

Use this summary when preparing the final release record.

• Release identifier: Record the version.
• Source revision: Record the immutable commit.
• Target environment: Identify the deployment target.
• Mandatory checks: Record pass, fail, blocked, and not-run counts.
• Open risks: Link unresolved findings and approved exceptions.
• Approval: Record the authorized decision-maker and decision date.
• Evidence: Link CI runs, test reports, security reviews, and deployment records.

17. Maintenance and governance¶

Review this checklist whenever release procedures, deployment architecture, security requirements, integration capabilities, or test acceptance criteria change.

The checklist supports release governance; it does not replace automated tests, security assessments, operational approval, or environment-specific deployment procedures.