chore: bump version to 9.3.1 across all components

[AnkanSaha]

Summary

This PR updates the project version from 9.3.0 to 9.3.1 across multiple files including documentation, VS Code extension, and the Go core.

Changes

• Updated VERSION file.
• Updated package.json in Documentation/ and Extension/.
• Hardcoded version strings updated in main.go and src/repl/repl.go.

Verification

• Verified banglacode --version outputs 9.3.1.
• Checked REPL version constant.
• Verified extension manifest version.

[github-actions]

🤖 Review Buddy - General Code Review

👥 Attention: @AnkanSaha

Oho @AnkanSaha! 'Added' title? Kya add kiya bhai? Confidence? Ya laziness?

Bhai, tune sirf version number 9.3.0 se 9.3.1 kiya hai aur PR title likha hai 'Added'. Matlab context gaya tel lene?

Aur ye manual hardcoding dekh ke toh mere aankhon mein acid gir gaya hai. 5 alag jagah version change kiya hai tune. Agar kal ko 9.3.2 karna ho, toh phir se 5 files khol ke baitega? Software Engineer hai ya sarkari office ka clerk jo har file pe manual stamp marta hai?

Code Quality Score: 2/10. Itna manual kaam toh mere dada ji bhi nahi karte the Excel mein.

---

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

[github-actions]

⚡ Review Buddy - Performance Analysis

👥 Attention: @AnkanSaha

Bhai, performance ki baat kare toh tune seedha developer ki productivity ki 'waat' laga di hai.

1. Human Latency (O(n) complexity):
   Tune version bump karne ke liye $n$ files manually edit ki hain. Agar $n=5$ hai, toh tune 5 baar wahi boring kaam kiya.
   Ab socho agar kal ko project bada ho gaya aur 50 files hui, toh kya tu pura din sirf version hi change karega?
   Tera 'manual update' algorithm O(n) hai, jabki ye O(1) hona chahiye tha.

2. Binary Bloat (Hardcoded Strings):
   main.go mein tune wo bada sa ASCII art aur version string hardcode kiya hai.
   fmt.Println ke andar itni badi strings runtime pe memory mein load hongi.
   Maana ki Go efficient hai, par ye hardcoded bawasir binary ka size faltu mein badhata hai.

3. Instruction Cache Miss (Logic wise):
   Jab tu hardcoded version use karta hai, toh har bar rebuild karna padta hai.
   Automation naam ki bhi koi cheez hoti hai duniya mein.
   Build time pe -ldflags use karke version inject kyu nahi kiya?

4. Context Switching Overhead:
   Ek developer jab itni saari files mein ek hi change dekhta hai, toh uska dimaag ghum jata hai.
   Review karne wale ka time waste, tera time waste.
   Isse achha toh thoda so gaya hota, kam se kam RAM toh bachti dimaag ki.

5. Maintenance Nightmare:
   Agli baar agar ek file miss ho gayi, toh version mismatch hoga.
   Application bolega 9.3.1, REPL bolega 9.3.0, aur tu baith ke debugging karega 'Bhai ye ho kya raha hai?'.
   Debugging is also a performance metric, aur wahan tu fail ho gaya.

6. CI/CD Inefficiency:
   Har bar manual change matlab har bar naya commit.
   Instead of having a single source of truth (like a VERSION file that is parsed),
   tu pure repo ka diff bada kar raha hai.
   Git history ki toh tune 'ma-behen' ek kar di hai.

7. CPU Cycles on String Concatenation:
   printVersion function mein tune manually ASCII boxes banaye hain.
   Har baar jab user --version chalayega, Go runtime ko wo saari strings stdout pe dhakelni padengi.
   Bhai, simple v9.3.1 likh deta toh kya chala jata?
   Ye design aesthetics ke chakkar mein performance ka gala ghot diya hai tune.

Recommendations:

• Use a single VERSION file and read it in Go using //go:embed.
• Use -ldflags "-X main.Version=9.3.1" during build.
• Stop hardcoding strings in package.json manually if you can script it.
• Use a single source of truth, nahi toh agle version mein tu pagal ho jayega.

---

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

[github-actions]

🔐 Review Buddy - Security Audit

👥 Attention: @AnkanSaha

Security ke naam pe tune wahi kiya jo log 'Password123' rakh ke karte hain.

Issue 1: Version Inconsistency (Integrity Risk)

• Severity: Low to Medium
• Location: main.go, repl.go, package.json (x2), VERSION
• Exploit: Agar tune galti se repl.go mein version update nahi kiya, toh user ko lagega wo purana version chala raha hai. Attackers purani vulnerability exploite kar sakte hain ye soch ke ki software updated nahi hai, ya phir fake sense of security mil sakti hai.
• Remediation: Single source of truth use kar bhai. Ek jagah change, har jagah reflect.

Issue 2: Information Disclosure (Hardcoded paths/Authors)

• Severity: Informational
• Location: main.go
• Observation: Tune ASCII art mein pura biodata de diya hai. Thik hai, cool lagta hai, par production binaries mein jitna kam metadata ho utna achha.
• Remediation: Version output ko clean rakho.

Issue 3: Supply Chain Verification

• Severity: Low
• Observation: package.json ke versions manual update ho rahe hain without any checksum validation of the build process.
• Remediation: Use automated release tools like semantic-release or goreleaser to ensure that what's in the code matches what's in the binary and the package registries.

---

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

[github-actions]

📊 Review Buddy - Code Quality & Maintainability Analysis

👥 Attention: @AnkanSaha

🎯 Overall Benchmark: 15/100 (Poor)

Bhai, Quality dekh ke toh aisa lag raha hai ki 'Code Quality' word tere dictionary mein 'Error 404' hai.

1. DRY (Don't Repeat Yourself) Principle Ka Murder:
   Tune '9.3.1' ko 5 baar likha hai. DRY principle ka tune 'Don't Repeat Yourself' se 'Do Repeat Yourself' bana diya hai.
   Quality code wo hota hai jahan ek change ek hi jagah karna pade.
   Tu yahan 'copy-paste' engineer ban gaya hai.

2. Hardcoding is a Sin:
   Go mein const Version = "9.3.1" in repl.go? Seriously?
   Aur phir main.go mein alag se hardcoded print statements?
   Bhai, agar tu kal ko Version variable ka naam badal dega, toh main.go phat jayega ya phir galat output dega.
   Interservice/Interpackage communication ke toh tune lode laga diye hain.

3. Single Source of Truth (SSOT) Missing:
   Tere paas ek VERSION file hai, par tu usey use nahi kar raha.
   Sirf wahan 9.3.1 likh dene se kuch nahi hota, code ko pata hona chahiye ki wo file exist karti hai.
   Go's embed package tera dost hai, use kar usey.

4. Naming Conventions:
   PR title 'Added'. Kya added? Version added? Feature added? Emotion added?
   Professionalism zero hai yahan. Conventional commits ka naam suna hai kabhi?
   chore: bump version to 9.3.1 likhta toh izzat badhti teri.

5. Magic Strings Everywhere:
   main.go mein wo ASCII art magic strings se bhara pada hai.
   Unko constants mein daal ya kisi template file mein rakh.
   Code file ko tune drawing board bana diya hai.

6. Lack of Automation:
   Version bump karne ke liye manually files edit karna 'Technical Debt' ki nishani hai.
   Ye debt tera credit card bill se bhi zyada tezi se badhega agar tune ise fix nahi kiya.

7. Extension and Documentation Desync:
   Agar tu Documentation ke package.json mein version badal raha hai, toh ensure kar ki docs ka content bhi updated hai.
   Sirf version number badalne se documentation update nahi hoti, bhai.

Refactoring Suggestion:

• VERSION file ko read kar Build process mein.
• Go code mein var Version string rakho aur -ldflags se populate karo.
• package.json ko kisi script se update kar (like npm version).
• Please, for the love of God, don't hardcode visual elements with version numbers.

---

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

[github-actions]

💡 Review Buddy - Best Practices & Alternative Suggestions

👥 Attention: @AnkanSaha

Bhai, ye manual versioning dekh ke 2005 ki yaad aa gayi. Thoda modern ban.

Suggestion 1: Use Build Flags instead of Hardcoding

Current Code (src/repl/repl.go):

const Version = "9.3.1"

Better Alternative:

// In your code
var Version = "development"

// During build
// go build -ldflags "-X 'github.com/nexoral/BanglaCode/src/repl.Version=9.3.1'"

Why: It removes the need to manually edit Go files for every release. Your CI/CD can handle it.

Suggestion 2: Single Source of Truth for Version

Current Code:
Hardcoded in VERSION, main.go, repl.go, and two package.json files.
Better Alternative:
Keep only the VERSION file and use a script (Bash/Python/Make) to sync it across other files before a release, or better yet, read the VERSION file at runtime using embed.

import _ "embed"

//go:embed VERSION
var Version string

Why: One source of truth means zero chance of version mismatch.

Suggestion 3: Conventional Commits

Current Title: Added
Better Alternative: chore(version): bump to 9.3.1 or fix: update version across packages
Why: Helps in generating changelogs automatically and makes the git history readable for humans (and not just for you after 3 drinks).

---

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:

• Manual versioning in 5 different files is a violation of the DRY (Don't Repeat Yourself) principle.
• Hardcoding versions in Go source code is outdated; should use build-time flags or an embedded VERSION file.
• The PR title 'Added' is completely useless and provides no context.
• Potential for version mismatch in future releases if any file is forgotten.

---

📋 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