feat: centralize versioning and add installation source detection

[AnkanSaha]

Summary

This PR updates the version to 6.16.41-stable across multiple files and introduces a feature to display the installation method in the banner.

Changes

• Version Bump: Updated VERSION, INSTALLATION.md, installer.sh, main.go, and Banner.go to 6.16.41-stable.
• Installation Metadata: Added logic in Banner.go to detect if the app was installed via NPM (via CONTAINDB_INSTALL_SOURCE env var) or Linux scripts.
• README Update: Added badges for Windows/macOS support and NPM availability.

Verification

• Run go run src/Core/main.go --version to verify version output.
• Run with CONTAINDB_INSTALL_SOURCE=npm to verify banner display.
• Checked installer.sh for correct versioning path.

[github-actions]

🤖 Review Buddy - General Code Review

👥 Attention: @AnkanSaha

Oye @AnkanSaha, ye kya bawasir bana diye ho? Version bump karne ke liye 6 files edit kardi? 1990s mein jee rahe ho kya?

Chacha Chaudhary wala dimaag lagaya hota toh ek hi jagah change karte. Pure project mein '6.16.41-stable' aise phelaya hai jaise shaadi mein raita. Aur ye ShowBanner mein logic ghusa diya? Separations of Concerns gaya tel lene?

Code Quality Score: 3/10 (Sirf isliye kyunki code compile ho jayega, par dil nahi jeet payega).

---

Generated by Review Buddy | Tone: roast | Language: hinglish

[github-actions]

⚡ Review Buddy - Performance Analysis

👥 Attention: @AnkanSaha

Bhai, performance ke naam pe tune system ka mazak uda diya hai.

1. Redundant String Allocations:
   Tu har file mein VERSION string define kar raha hai. Go compiler smart hai, par tera code 'Stupid' hai. Har constant ke liye binary mein alag memory space allocate ho rahi hai.

   • src/Core/main.go -> VERSION := "6.16.41-stable" (Stack allocation if not escaped, but still useless).
   • src/base/Banner.go -> const Version = "6.16.41-stable" (Data segment).
   • Ek hi string ko 10 jagah likh ke tune binary size badha diya hai. Chalo, bytes mein hai, par 'Death by a thousand cuts' suna hai?

2. Runtime OS Detection In Banner:
   runtime.GOOS check karna output dikhane ke liye? Ye kaam build time pe ldflags se ho sakta tha.

   // Bad Approach (Tera Code)
   if runtime.GOOS == "linux" { ... }

   Har baar jab user banner dekhega, CPU ek faltu branch instruction execute karega. Binary mein dono paths compile honge.

3. Environment Variable Latency:
   os.Getenv("CONTAINDB_INSTALL_SOURCE") call kar raha hai banner dikhane ke liye.
   System calls are expensive, beta. Banner dikhana ek O(1) operation hona chahiye tha, tune usse OS dependent bana diya.

4. Color Library Overhead:
   fatih/color use kar raha hai, thik hai. Par boldCyan("📦 Version:") calls internal buffer use karte hain aur string manipulation karte hain.
   Agar ye CLI tool script mein use hua (jahan koi banner nahi dekhta), tab bhi tu ye sab calculate karega?

5. Binary Bloat:
   Hardcoding version in main.go, Banner.go, installer.sh, VERSION file, README.md, and INSTALLATION.md.
   Update karte waqt agar ek bhi miss hua (jo tu pakka karega), toh metadata inconsistency ki wajah se debugging mein nani yaad aa jayegi.

6. Recommendation:

   • Use -ldflags "-X 'github.com/nexoral/ContainDB/src/base.Version=6.16.41'" during build.
   • Ek internal/version package bana aur wahan se import kar.
   • Garbage Collection (GC) ko kaam mat de faltu ki strings bana ke.

Tumse na ho payega, thoda optimization seekho.

---

Generated by Review Buddy | Tone: roast | Language: hinglish

[github-actions]

🔐 Review Buddy - Security Audit

👥 Attention: @AnkanSaha

Security Audit Report: 'ContainDB Version Chaos'

1. Issue: Trusting Unauthenticated Environment Variables

   • Severity: Low (but annoying)
   • Location: src/base/Banner.go line 51
   • Exploit: Koi bhi user export CONTAINDB_INSTALL_SOURCE="NPM Package" karke system ko chutiya bana sakta hai. Agar ye info kisi security decision ya audit log mein use hoti hai, toh game khatam.
   • Remediation: Don't rely on env vars for 'Installation Method' unless you verify them against a signed manifest.

2. Issue: Missing Checksum Verification in Installer

   • Severity: High
   • Location: Scripts/installer.sh and INSTALLATION.md
   • Exploit: wget se .deb file download kar raha hai bina SHA256 check kiye. Man-in-the-middle (MITM) attack hua toh user ke system mein malware install ho jayega aur wo tujhe gaali dega.
   • Remediation: Always provide a checksum (SHA256) and verify it in the script: echo "$HASH $PKG" | sha256sum -c -.

3. Issue: Insecure Package Installation Command

   • Severity: Medium
   • Location: INSTALLATION.md line 25
   • Exploit: sudo dpkg -i manual download ke baad chalana risk hai. Agar download corrupted hai, toh dpkg behavior unpredictable ho sakta hai.
   • OWASP Reference: A08:2021-Software and Data Integrity Failures.

4. Issue: Path Injection Potential (Theoretical)

   • Severity: Low
   • Location: installer.sh
   • Analysis: ARCH variable is coming from dpkg --print-architecture. If the environment is compromised and dpkg is replaced with a malicious script, ARCH could contain injection payloads. Always sanitize output from external commands.

---

Generated by Review Buddy | Tone: roast | Language: hinglish

[github-actions]

📊 Review Buddy - Code Quality & Maintainability Analysis

👥 Attention: @AnkanSaha

🎯 Overall Benchmark: 40/100 (Poor)

Quality Analysis: 'Code Quality Ka Janaza'

1. Category: DRY Principle Violation (Severity: CRITICAL)

   • Location: Everywhere.
   • Explanation: 'Don't Repeat Yourself' ko tune 'Definitely Repeat Yourself' bana diya hai.
     Version string is hardcoded in 5 different files.
     • INSTALLATION.md (2 spots)
     • Scripts/installer.sh (1 spot)
     • VERSION (1 spot)
     • src/Core/main.go (1 spot)
     • src/base/Banner.go (1 spot)
   • Refactoring: Create a single VERSION file and let your CI/CD or Build scripts inject that version into the Go binaries using -ldflags.

2. Category: SOLID - Single Responsibility Principle (Severity: MEDIUM)

   • Location: src/base/Banner.go
   • Explanation: ShowBanner() ka kaam hai banner dikhana. Lekin tu uske andar OS detect kar raha hai, Environment variables check kar raha hai, aur installation logic decide kar raha hai.
   • Refactoring: Logic ko alag function mein daal GetInstallMethod(). Banner ko sirf string chahiye print karne ke liye. UI logic aur business logic ko mix mat kar, varna logic fail hone pe UI bhi phat jayega.

3. Category: Error Handling (Severity: LOW)

   • Location: src/Core/main.go line 15
   • Explanation: if len(os.Args) > 1 && os.Args[1] == "--version" is very primitive.
   • Refactoring: Use a proper flag parsing library like cobra or flag. Kal ko user -v ya -version likhega toh tera code 'Bhagwan Bharose' hai.

4. Category: Magic Strings & Hardcoding (Severity: MEDIUM)

   • Location: src/base/Banner.go lines 50-56
   • Explanation: "NPM Package", "Manual Installation", "Linux Script/Package" - ye sab magic strings hain.
   • Refactoring: Define these as Enums or Constants at the top. Hardcoding strings deep in logic is a technical debt magnet.

5. Category: Documentation Inconsistency (Severity: LOW)

   • Location: README.md
   • Explanation: Added badges for macOS and Windows, but the installer.sh and INSTALLATION.md only talk about Debian/Ubuntu.
   • Refactoring: Agar platform support badh gaya hai, toh installation steps bhi toh update karo! Sirf badge chipkane se software cross-platform nahi ban jata.

6. Conclusion:
   Tera code 'Spaghetti' toh nahi hai, par 'Maggi' zaroor hai - jaldi mein banaya gaya aur nutrition (quality) bilkul zero. Fix the DRY issues immediately before this repo becomes a maintenance nightmare.

---

Generated by Review Buddy | Tone: roast | Language: hinglish

[github-actions]

⚠️ Review Buddy - Final Recommendation

👥 Attention: @AnkanSaha

Recommendation: REQUEST CHANGES

Changes chahiye, bhai! Abhi approve nahi kar sakte.

Reasoning:

• Kuch security concerns ya quality issues hain jo fix karne padenge.
• Suggestions ko address karo, improvements karo.
• Sab fix hone ke baad hi approve hoga.

---

📋 Review Checklist for Reviewers:

• Code changes align with the PR description
• No security vulnerabilities introduced
• Performance considerations addressed
• Code follows project conventions
• Tests are adequate (if applicable)
• Documentation updated (if needed)

🎯 Next Steps:

⚠️ Pehle suggestions address karo, phir approve karna.

Generated by Review Buddy | Tone: roast | Language: hinglish