docker102

This proposal is structured for management to emphasize a structured, low-risk approach to recovering the etsf library while addressing the practicalities of cross-team collaboration.

Management Proposal: Recovery Strategy for Legacy CPLS Artifacts

Executive Summary

Recent audit of the CPLS (formerly COMET) application stack has identified the etsf library as a critical dependency that is currently present in Artifactory but missing from the GitHub source code repository. Given its 2025 activity, this is likely a migration "orphan." I propose a Reverse-Chronological Forensic Recovery (Divide-and-Conquer) to restore this asset from BitBucket backups.

Proposed Recovery Methodology

We will use a search-and-validate loop to minimize time spent on irrelevant legacy data:

Phase 1: The "High-Confidence" Window (Q3 2025)
- Action: Direct the BitBucket Infrastructure team to restore the Full Backup from Q3 2025 (aligned with the last Artifactory update on Aug 25, 2025).
- Validation: Compare restored code against the disassembled JAR from Artifactory using class-level checksums.
Phase 2: Narrowing (Weekly Incrementals)
- Action: If the Q3 backup matches, pull the subsequent weekly incrementals to find the absolute latest commit before the library was deleted or migrated.
Phase 3: Fallback (Quarterly Regression)
- Action: If Q3 2025 is empty, move back in quarterly increments (Q2 2025, Q1 2025, etc.) until the source is located.

Practicality & Resource Assessment

Working with the Central Hub/Infrastructure teams is practical, but success depends on precise documentation.

Is it "Monthly"? No. If we provide the specific Artifact ID (etsf) and Group ID (com.citi.158825.ETSFb), a search of a specific backup volume usually takes 24–48 hours for the team to run. The "months" of delay usually come from vague requests; specific IDs and dates bypass this.
The "Ticket" Requirement: Yes, an official ticket is mandatory. In most enterprise environments, Infrastructure teams cannot access backup vaults without a tracked request for audit and compliance purposes.

Action Plan & Internal Instructions

Required Ticket Details

To avoid back-and-forth, the ticket should include:

Service: Source Control Recovery (BitBucket Legacy)
Target Repo/Path: com/citi/158825/etsf
Specific GroupID: com.citi.158825.ETSFb
Priority Date: August 25, 2025 (Last known deployment)
Request: "Restore the repository state from the last full backup prior to Sept 1, 2025."

Collaborative Instructions for Hub Teams

To BitBucket Admins: "Identify the last active 'Project Key' associated with the etsf artifact. If the repo was deleted, provide the deletion log entry to identify the decommissioning owner."
To GitHub Migration Team: "Audit the 'Migration Exclusion List' for the 2025-2026 cycle to see if 158825 was intentionally scoped out due to its Java 6 status."

Risk Mitigation

By comparing any found source code against the disassembled code from Artifactory, we eliminate the risk of "version mismatch." We are not just looking for any code; we are looking for the code that matches the binary currently running in our environment.

Recommendation: Proceed with a High-Priority Infrastructure ticket today to initiate the Q3 2025 search.

Does the CPLS migration timeline allow for a 48-hour buffer to wait for these backup results?