Confirm ASI release requirements and approval path
Use the existing ASI handoff as the starting point, not a new generic questionnaire. Ricci told Elazar: 'No los despliegues, los hago yo; vos solamente pasame el TAG.' April ASI email specifies S2I/port 8080 and existing DB provision; April training describes a Git release-candidate tag, ASI-built image and one QA-to-HML-to-PRD ticket; Sept 29 records QA OpenID request RE-1697147 resolved and DB credential handoff RE-1696847. Do not request, expose or rotate those credentials. Our responsibility is a reproducible QA candidate: exact repo commit/tag proposal and sanitized source tree, QA-specific README/UPGRADE/CHANGELOG, DB baseline/delta/rollback and owner, config/Secret references, test/security evidence, and a handoff ticket draft. Ricci/ASI owns QA deployment. Resolve only concrete gaps still not established by existing evidence: actual QA target/job source ref and execution owner, QA DB installed baseline and authorized delta, runtime secret/probe/integration wiring, and candidate acceptance gates. QA assessment, HML user signoff and ASI PRD promotion follow QA entry; they are not prerequisites to package preparation. A develop mirror or healthy DEV pod is not QA acceptance. Record each unresolved item with owner and evidence; do not push a tag or deploy QA without Elazar's release authorization.
Activity
-
parent=#4648
-
was: Get ASI written confirmation of the current GitLab repo and layout, DEVELOP to MASTER/tag process, deploy-ticket template, QA assessment, HML user signoff, production promotion owner and acceptance evidence after migration. Reconcile ES0901 v6.4 with the April training. Done when a requirements matrix separates mandatory first-release gates from assumptions and names every unresolved ASI decision.
-
First action: obtain written ASI rulings before packaging or changing delivery paths.
-
was: Get written ASI decisions before implementation: confirm the current formal Git repository, branch/tag and post-GitLab-migration handoff; QA, HML and PRD approval path and named approvers; existing ASI database baseline, target database and owner/operator; whether a DEV dump is requested or allowed; data/PII handling and configuration/secret ownership. Record answers and release dependencies on this item. Do not infer formal acceptance from a develop mirror or healthy DEV pod.
-
was: Get written ASI decisions before implementation: current formal Git repository, branch/tag, ticket and post-GitLab handoff; QA/HML/PRD approval path and named approvers; ASI DB baseline, target and operator; whether a DEV dump is requested or allowed; data/PII scope; current credential and Secret/ConfigMap policy. Locate and cite the April ASI training artifact. The April note requested ConfigMap while the pod now uses Secret, so neither alone establishes current policy. Record answers and dependencies; a develop mirror or healthy DEV pod is not formal acceptance.
-
coder03-mba-l-ca / pm
-
Using existing ASI emails, ES0901, training and migrated GitLab evidence; do not re-request supplied credentials.
-
Evidence inventory 2026-10-16: April MovilBA ASI email establishes S2I, port 8080, manifest master, existing ASI DB and dump only on manual restore request. Elazar supplied Ricci's 2026-09-29 email containing DEV+QA OIDC client secrets and DB password; do not request or store values again. Migration notes RE-1697147 record a reissued QA client ID, contrary to Ricci's 'same IDs' sentence. ES0901 v6.4 and April training describe master candidate tag, QA-built immutable image, one QA-to-HML-to-PRD ticket. Current mba-deploy-pod.sh only force-pushes sanitized develop to DEV, and local repo has no tags. This is process evidence, not proof of current migrated QA cluster/DB state or approval. Coder04/db04/audit doing independent scoped checks; no external push or QA change.
-
was: First obtain current written ASI rulings, citing response date/version and named owner: formal repo/branch/tag/ticket path after GitLab migration; QA, HML and ASI PRD approvers; existing ASI DB baseline/target/operator and DEV dump purpose; data/PII scope; credential and Secret/ConfigMap policy; required integrations and docs. Locate April training artifact. Distinguish answered release blockers from deferred nonblockers, each with owner and decision. August standard/April note do not alone prove current policy. A develop mirror or healthy DEV pod is not acceptance.
-
Ricci's direct instruction supplied by Elazar on 2026-10-16: 'No los despliegues, los hago yo; vos solamente pasame el TAG.' Treat TAG as the Git release-candidate tag described in April training; our handoff is proposed exact commit/tag and package, while Ricci/ASI builds/deploys QA. db04 confirms only missing DB input is read-only QA schema/state inventory and named DB operator/dump decision, not credential reissue. No tag push, QA deployment, import or restore authorized in this preparation.