Assess release readiness
Use this page to distinguish current release readiness from historical prototype and deployment evidence.
Current readiness
Release 1.0.0 is not ready for production promotion. Production GitOps revision 5a440bbe62b4d284b8b8ce81c2afeb79a974f762 is Synced / Healthy and selects application/source revision dbba4a186a02cb4567c64f1c3400d38556aa1a25, but the desired state still declares release 1.0.0.2 and chart 1.0.0+build.3. That release identity was already rejected and must not be reused for the corrective images now deployed under different immutable digests. The next candidate requires a new release and chart identity, a complete UAT_PASSED deployment tuple, and an explicit release request and production-promotion approval from RootAtSkic.
| Current corrective deployment identity | Development | Production |
|---|---|---|
| Application/source revision | 9bdc1a093b0f8ae306708bea591f898dfe6adb20 | dbba4a186a02cb4567c64f1c3400d38556aa1a25 |
| GitOps revision | b2241bc016940c8bf9b803ace2493ab83eac7dd9 | 5a440bbe62b4d284b8b8ce81c2afeb79a974f762 |
| Argo CD state | Synced / Healthy | Synced / Healthy |
| Nebula image digest | sha256:74211e14f8bac2ac9bafaa89e3d44905886a1f93bf339b3fb33e77feba0724f7 | sha256:d6204a4615e6963c5e7fe1fab6226d7980d0abe9b9db86bdb89d45331acf53e9 |
| Singularity image digest | sha256:700a7b1f54e1829f5b8f6b766ce8a05453f436ef73871f95d3dd6e7f18bc5581 | sha256:36bd6e5ef71e34cba95e58c63a3c770f797d978c5d1f2048190c943b27f68ec6 |
Development was reverified on 2026-10-01; the production column retains its last recorded observation and was not revalidated or changed by this correction. The current development tuple, including chart 1.0.0+build.3.9bdc1a093b0f8ae306708bea591f898dfe6adb20 and template 6f0916a2ce06c9aaa7499bfdd5b08098ab3b3088, is handed to UAT in message 1555008862283759636. No earlier browser result transfers to this tuple.
The canonical inventory contains 174 Tasks: 161 DONE, 0 READY_FOR_DELIVERY, 0 IN_PROGRESS, 5 TO_BE_RELEASED, and 8 IN_BACKLOG. TASK-0175 records the exact authorized Coastal Range model replacement and owner-requested airborne airport start. Implementation, publication and development deployment are verified through application PR330, template PR85 and development PR62. The canonical state is ToBeReleased; independent UAT acceptance and production release remain pending. Recovery is tracked on AeroSim Delivery. TASK-0174 records the compact flight-controls HUD correction merged in application PR326 and deployed through template PR82 and development PR59; technical Delivery is verified while independent visual/functional acceptance remains pending. TASK-0173 maps runtime correction t_5f3a1958, technically delivered to development and handed to independent UAT; historical page-error attribution remains open. TASK-0172 maps Delivery correction t_8aebf315: its code and technical handoff are complete on the cumulative development tuple, with visual acceptance targets handed to UAT. Independent visual acceptance remains pending. TASK-0171 is the post-delivery correction that removes the redundant camera confirmation step; its exact immutable tuple is deployed to development and handed to UAT while RootAtSkic retains actual UX verification. Release 1 Waves 33–35—TASK-0149 through TASK-0163—are DONE. The nine Wave 33–34 records were reconciled with hash-linked release-completion events after their integration revisions were verified as ancestors of the same deployed cumulative application revision that closed Wave 35. This technical closure does not make a rejected release acceptable, supply missing UAT_PASSED evidence for a new candidate, or replace explicit human post-release acceptance. Earlier unauthenticated UAT journey results are historical and do not transfer to this development tuple. The previously recorded authenticated-journey blocker remains open: the E2E storage-state contract cannot preserve the application's in-memory OIDC session across page recreation. Human post-release acceptance remains PENDING.
Blocking gates
- Correct the E2E authenticated-session contract and obtain complete
UAT_PASSEDevidence against one frozen development deployment tuple. - Allocate a new immutable replacement identity instead of reusing rejected
1.0.0.2/ chart1.0.0+build.3. - Obtain RootAtSkic's explicit release request and exact production-promotion approval.
- Promote and verify the exact accepted tuple, then record explicit human post-release acceptance separately after deployment.
Last rejected candidate
| Identity | Verified value |
|---|---|
| Product release | 1.0.0.2 |
| Application and chart source | 8a448c70fcf09e05fc7b75f078572a85b92b6cf6 |
| Helm chart | 1.0.0+build.3 |
| Helm OCI digest | sha256:dceace9ffa94054c6f0f0b114d55b3edd240dab504cf254b3cd48137a5a5437f |
| Nebula image digest | sha256:63f8975c9ae25b165dc271e1f084f9a45938e88154124bcc75f73b7fbc7e4b73 |
| Singularity image digest | sha256:30130f718b43e3bad7cb156586642d15cbf739baca1891f6bfede4ecf5f6d15b |
| Template integration | ae0d8d62cd6d5f65fd8832891ce62144db760e4c |
| Rendered integration / deployment revision | 999b9c39288e187cbacc0f8f6e1165a58a56f4fa |
| Previous rejected GitOps revision | 4222fc84c6e75b486951b42037776a5c167c77ea |
Application PR #216, template PR #16, and rendered PR #26 merged after exact-tree review and validation.
Exact-head and post-merge validation passed for the application, template, and rendered GitOps revisions. Template tests, rendered Python/Node/shell checks, authoritative render equality, selector preflight, Kubernetes server dry-run, and 376/376 Conftest policy checks passed before deployment.
Release notes and operational plan
Wave 32 corrects the two defects that caused human rejection of 1.0.0.0: the initial-camera selector now supports ordinary full-card interaction with an immediate visible selected state, and every supported world now uses the RootAtSkic-approved production-scale boundary policy of 20000 m warning, 25000 m hard limit, and 2000 m return hysteresis.
No database schema migration was introduced. Compatibility preserves PostgreSQL storage, the Keycloak ExternalSecret, public routes, Services, API base, and Socket.IO contracts. The rejected 1.0.0.0 GitOps revision 5d3712d89dfbf7dacd993348e55f497d126c7bf9 and artifacts remain immutable rollback inputs; rollback is ready but was not invoked.
Production acceptance — deployed, UAT failed, product rejected
Argo CD reconciled chart 1.0.0+build.3 as Synced / Healthy. Web and API pods are ready with zero restarts, observed image IDs equal the selected immutable digests, and UI, API health, and Socket.IO polling routes returned HTTP 200. Runtime configuration reports product release 1.0.0.2.
A fresh real Keycloak login and full Home → aircraft → world → conditions → camera → launch path succeeded. The 36-journey UAT covered all three worlds, all nine aircraft, all four cameras, and all three condition presets through ordinary visible interaction.
All 36 journeys failed product usability. Thirty-three journeys changed attempt identity or regressed source sequence without an explicit restart. The representative control diagnostic showed that key events change visible control values, but every world entered an uncommanded climbing left turn during the first neutral five seconds and later reset; Training Airfield and Coastal Range also emitted Trainer snapshot time must increase. Visual evidence shows wrong or broken world composition, nine unusable cockpit journeys, five black/empty final frames, and foreign wing-shaped or aircraft-like geometry rendered alongside the active plane. Three follow-up recordings confirmed neutral eight-second heading changes from 000° to 341°, 341°, and 339°, climbs from 39 ft to 193, 197, and 212 ft, and implicit attempt replacement at approximately 29.4, 29.8, and 29.6 seconds. RootAtSkic's findings are recorded in Discord message 1550551559899848705, message 1550580266580447333, and message 1550583772309889217. Release 1.0.0.2 is therefore REJECTED for product acceptance while remaining deployed for investigation.
The current structure is defined by canonical YAML and the clean-slate Scope decision. Materially redefined records do not inherit the old scenario-led approvals, task execution state, acceptance findings, version allocation, or release claims.
Historical readiness snapshot
Prior application, CI, GitOps, runtime, and browser observations remain useful prototype and discovery evidence only. They may inform feasibility and future Architecture derivation, but they do not establish current Scope acceptance, implementation approval, Task completion, release selection, or deployment of the current definitions.
Historical operational evidence must remain bound to the exact source and runtime revision it observed. It must not be presented as evidence for materially redefined current records.
Current release-entry gates
A releasable candidate requires all of the following current evidence:
- exact current Scope decisions for the included Features;
- current Architecture requirements, solution decisions, and implementation authorization;
- exact Task transitions with reviewed implementation and validation evidence;
- every required Task at
TO_BE_RELEASEDorDONE; - an allocated version and immutable candidate identity;
- compatibility, migration, rollback, observation, and acceptance ownership;
- deployment and post-deployment evidence bound to that exact candidate.
Approval, CI success, artifact publication, deployment health, and visible prototype behaviour remain separate dimensions. None substitutes for another or silently advances current delivery state.