added files

ai-blitz/README.md

@@ -0,0 +1,45 @@
+# AI Blitz — devops-lib task catalogue
+
+Tasks identified for the AI Blitz Week 3 capstone (Task 11 from the Week 3 playbook). Each task is a small, agent-doable unit of work grounded in real findings from `BUGS_AND_IMPROVEMENTS_REPORT.md`, `docs/tribal-knowledge.md`, and `review-learnings.md`.
+
+## Mix
+
+5 tasks: 3 small features + 2 bug fixes.
+
+| # | Task | Type | Files touched (rough) | Difficulty |
+|---|---|---|---|---|
+| 01 | [`task-01-securityScan-hardcoded-ip.md`](task-01-securityScan-hardcoded-ip.md) | Bug fix (P0 security) | 2 | low |
+| 02 | [`task-02-checkoutSubmodule-typo.md`](task-02-checkoutSubmodule-typo.md) | Bug fix (correctness) | 1-2 + consumer repos | medium |
+| 03 | [`task-03-onlyPushtoJfrog-jdk-versions.md`](task-03-onlyPushtoJfrog-jdk-versions.md) | Small feature | 1 | low–medium |
+| 04 | [`task-04-buildPipeline-agent-label-param.md`](task-04-buildPipeline-agent-label-param.md) | Small feature | 3 | low |
+| 05 | [`task-05-cloudFunctionCICD-implementation.md`](task-05-cloudFunctionCICD-implementation.md) | Small feature | 4-5 + 1 consumer | high |
+
+## Capstone picks
+
+| Day | Mode | Task | Why this pick |
+|---|---|---|---|
+| Day 4 (Thu) | Interactive (war-room) | **Task 05 — Implement `cloudFunctionCICD`** | Real design decisions throughout (gen-1 vs gen-2 syntax, runtime → buildObjHelper mapping, service-account auth path). Maximises learning signal when humans correct the agent in real time. |
+| Day 5 (Fri) | Autonomous | **Task 02 — Fix `chekoutSubmodule` typo** | Clear acceptance criteria, mostly mechanical, the deprecated-alias-with-log-warning pattern is recognisable. Agent can solo without supervision. |
+
+## Adding a new task
+
+1. Copy [`_TEMPLATE.md`](_TEMPLATE.md) to `task-NN-<short-slug>.md`.
+2. Number sequentially (next is 06).
+3. Fill out Goal + Acceptance Criteria. Cite a source — `BUGS_AND_IMPROVEMENTS_REPORT.md` §, `docs/tribal-knowledge.md` §, or a specific `review-learnings.md` rule ID.
+4. Update the table above.
+
+## Source documents the catalogue draws from
+
+- [`../BUGS_AND_IMPROVEMENTS_REPORT.md`](../BUGS_AND_IMPROVEMENTS_REPORT.md) — known bugs + tech debt
+- [`../docs/tribal-knowledge.md`](../docs/tribal-knowledge.md) — non-obvious conventions
+- [`../review-learnings.md`](../review-learnings.md) — PR-review-derived rules
+- [`../docs/architecture.md`](../docs/architecture.md) — module map, downstream services, invariants
+
+## Out of scope
+
+Tasks **not** in this catalogue (good candidates, but not picked):
+
+- Full test-harness bootstrap (JenkinsPipelineUnit) + first unit tests — large scaffolding effort, deferred to a dedicated PR.
+- ArgoCD `--password-stdin` refactor — pure refactor, no behavioural change; lower learning value.
+- Refactor `validate_configs.py` (1207 lines) into modules — too large for a single Blitz task.
+- `xq` (XML query) → Groovy parser on Gradle files in `buildGradle.groovy` — same reason.

ai-blitz/_TEMPLATE.md

@@ -0,0 +1,20 @@
+# Task NN: <Title>
+
+- **Type:** Feature / Bug fix / Refactor / Test gap
+- **Source:** `<file>.md` §<section> or `review-learnings.md` `<RULE_ID>`
+
+## Goal
+
+One sentence: what should be true after this task is done.
+
+## Acceptance Criteria
+
+- [ ] Observable behaviour 1
+- [ ] Observable behaviour 2
+- [ ] Tests added/updated covering the new behaviour (skip if devops-lib has no test suite — note that here)
+- [ ] All existing tests pass (or: smoke-test via `@Library('devops-lib@<branch>')` from a sandbox consumer Jenkinsfile)
+- [ ] Docs updated if the task changes a documented behaviour (`README.md`, `CLAUDE.md`, `docs/tribal-knowledge.md`, `docs/architecture.md`, the relevant `review-learnings.md` rule)
+
+## Notes / known gotchas
+
+(Optional — surface design decisions or constraints the agent should know upfront.)

ai-blitz/task-01-securityScan-hardcoded-ip.md

@@ -0,0 +1,22 @@
+# Task 01: Replace hard-coded IP in `securityScan.groovy` with DNS hostname
+
+- **Type:** Bug fix (security, P0)
+- **Source:** `BUGS_AND_IMPROVEMENTS_REPORT.md` §2.1 + `review-learnings.md` rule `P0_HARDCODED_IP_IN_PIPELINE`
+
+## Goal
+
+`src/com/meesho/stages/securityScan.groovy` no longer references a bare IP for the scanner endpoint; the `P0_HARDCODED_IP_IN_PIPELINE` rule in `review-learnings.md` no longer needs the "known exception" carve-out for this file.
+
+## Acceptance Criteria
+
+- [ ] `securityScan.groovy:11` uses a DNS hostname (e.g. `security-scan.meeshogcp.in` or whatever DevOps allocates) instead of `172.31.5.29:63232`
+- [ ] If no DNS exists yet, the task surfaces a DevOps ask before merging — does **not** ship with a placeholder IP
+- [ ] `grep -rE '\b(172|10|192)\.[0-9]+\.[0-9]+\.[0-9]+:[0-9]+' src/com/meesho/ vars/` returns zero hits for HTTP/curl targets
+- [ ] `review-learnings.md` rule `P0_HARDCODED_IP_IN_PIPELINE` has its "known exception: securityScan.groovy:11 uses 172.31.5.29:63232 pending remediation" carve-out **removed** in the same PR
+- [ ] No retry / behavioural change — same POST shape, single call, only the hostname changes
+- [ ] Smoke-test via a Jenkins job pointed at `@Library('devops-lib@<branch>')` confirming the scan POST succeeds against the new DNS
+
+## Notes / known gotchas
+
+- The receiver is a Meesho-internal scanner — coordinate with the security team to confirm the DNS name and that it's reachable from the Jenkins agent pod's network policy.
+- Don't add a fallback to the IP "just in case" — the whole point of the rule is to fail loud on DNS issues, not to silently drop back to a hardcoded address.

ai-blitz/task-02-checkoutSubmodule-typo.md

@@ -0,0 +1,30 @@
+# Task 02: Fix `chekoutSubmodule` method-name typo across all call sites
+
+- **Type:** Bug fix (correctness)
+- **Source:** `BUGS_AND_IMPROVEMENTS_REPORT.md` §1.2
+
+## Goal
+
+Method name in `src/com/meesho/stages/checkOut.groovy:20` reads correctly as `checkoutSubmodule`; every caller in the codebase resolves; consumer Jenkinsfiles that reference the old name don't break overnight.
+
+## Acceptance Criteria
+
+- [ ] `checkOut.groovy:20` defines `def checkoutSubmodule(String repo_name)` — not `chekoutSubmodule`
+- [ ] Every `grep -rn 'chekoutSubmodule'` hit in `src/`, `vars/`, `resources/` is updated to `checkoutSubmodule`
+- [ ] Cross-org sweep: search `Meesho/*` for `chekoutSubmodule` references and either:
+  - (a) raise companion PRs on each consumer to update the call, **or**
+  - (b) add a backwards-compat alias in `checkOut.groovy`:
+    ```groovy
+    def chekoutSubmodule(String repo_name) {
+        log.warning('chekoutSubmodule is deprecated — use checkoutSubmodule')
+        return checkoutSubmodule(repo_name)
+    }
+    ```
+- [ ] Alias (if present) is documented in a `CHANGELOG`-style note with a target removal date
+- [ ] Smoke-test via a consumer Jenkinsfile that exercises the submodule checkout path
+- [ ] No behavioural change in the underlying method body — only the name changes
+
+## Notes / known gotchas
+
+- The alias path is the safer choice in a shared library — consumer Jenkinsfiles get reviewed and merged on their own schedule, and a hard rename will silently fail across the org.
+- Once the alias is in, run `gh search code 'chekoutSubmodule' --owner Meesho --json repository,path` periodically to track removal readiness.

ai-blitz/task-03-onlyPushtoJfrog-jdk-versions.md

@@ -0,0 +1,22 @@
+# Task 03: Complete JDK version handling in `onlyPushtoJfrog.groovy`
+
+- **Type:** Small feature
+- **Source:** `BUGS_AND_IMPROVEMENTS_REPORT.md` §1.5
+
+## Goal
+
+When a user picks JDK 11 or JDK 21 in the `onlyPushtoJfrog` choice parameter, the job runs under that JDK — not the JDK 8 fall-through default.
+
+## Acceptance Criteria
+
+- [ ] `vars/onlyPushtoJfrog.groovy:16` choice parameter remains `['jdk8', 'jdk11', 'jdk17', 'jdk21']` (no values removed)
+- [ ] The if/else at `vars/onlyPushtoJfrog.groovy:48-53` handles **all four** JDK selections, each setting the correct `JAVA_HOME` path that exists in the build-tools pod image
+- [ ] An unknown JDK selection (shouldn't happen via the choice param, but defensive) sets `JAVA_HOME` to a fail-fast value and logs `log.error("Unknown jdk_version: ${jdk_version}")` instead of silently defaulting to JDK 8
+- [ ] Verify the JDK paths against the actual `devops-tools:lunar-vX.Y.Z` image used by `prd-pod.yaml` / `stg-pod.yaml`. If `jdk11` or `jdk21` aren't in the image, raise a `tribal-knowledge §12` follow-up (bump the build-tools image tag) **before** this task can complete
+- [ ] Smoke-test all 4 JDK selections via a sandbox Jenkins job — confirm `java -version` reports the expected JDK in each run
+- [ ] No behavioural change for `jdk8` / `jdk17` selections — those branches stay identical
+
+## Notes / known gotchas
+
+- The fall-through bug is silent: builds "succeed" with the wrong JDK, which can mask bytecode-version incompatibilities or break records of which JDK actually built the artifact. The fail-fast on unknown values is intentional.
+- `tribal-knowledge.md` §12 calls out that toolchain binaries belong in the pod image, not curled at build time — keep this task aligned with that convention.

ai-blitz/task-04-buildPipeline-agent-label-param.md

@@ -0,0 +1,26 @@
+# Task 04: Make Jenkins agent label configurable via `agent_label` parameter
+
+- **Type:** Small feature
+- **Source:** `BUGS_AND_IMPROVEMENTS_REPORT.md` §3 (hard-coded `node('slave02')` in `vars/buildPipeline.groovy:16`)
+
+## Goal
+
+`buildPipeline { ... }` consumers can override the Jenkins agent node label without forking the library; existing consumers (no override) still pin to `slave02` so nothing breaks.
+
+## Acceptance Criteria
+
+- [ ] `vars/buildPipeline.groovy:16` reads `param.agent_label` and falls back to `'slave02'` when unset:
+  ```groovy
+  def agentLabel = param.agent_label ?: 'slave02'
+  node(agentLabel) { ... }
+  ```
+- [ ] `README.md` `## Optional parameter` section documents `agent_label` with the same shape as the other params (key, type, default, description). Default must be the legacy `slave02` for backwards compatibility
+- [ ] A consumer Jenkinsfile that passes `agent_label: 'gke-build-agent'` runs on that node; one that omits it still runs on `slave02`
+- [ ] `grep -rn "node\('slave02'\)" vars/ src/` shows zero hard-coded uses **other than the fallback string in `buildPipeline.groovy`**. If other files hard-code the same node, list them out and either fix in the same PR or open follow-up tasks
+- [ ] Smoke-test: one PR pipeline with the override, one without
+- [ ] Add a `## NEVER DO` entry to `CLAUDE.md`: *"Don't add new `node('<literal>')` blocks in `vars/`. New entry points must accept `agent_label` from the param map and fall back to `'slave02'` or a documented default."*
+
+## Notes / known gotchas
+
+- `eksCICD.groovy` and `gkeCICD.groovy` use `podTemplate(yaml: libraryResource("org/meesho/${env.INFRA_ENV}-pod.yaml"))` instead of a `node()` block — they're outside the scope of this task. Only `buildPipeline.groovy` (and any other `node('<literal>')` callers grep finds) needs the change.
+- Don't change the default to `null` or empty — services in the org currently rely on the implicit `slave02` pin; flipping the default mid-flight will silently move builds to whichever agent the master picks.

ai-blitz/task-05-cloudFunctionCICD-implementation.md

@@ -0,0 +1,40 @@
+# Task 05: Implement the `cloudFunctionCICD` skeleton
+
+- **Type:** Small feature
+- **Source:** `BUGS_AND_IMPROVEMENTS_REPORT.md` §1.6 (`cloudFunctionCICDFlow()` is currently a stub containing only `sh 'ls -al'; echo 'Hello World'`)
+
+## Goal
+
+`vars/cloudFunctionCICD.groovy` actually deploys a GCP Cloud Function. Services that use `cloudFunctionCICD { ... }` get a working pipeline instead of the current no-op skeleton.
+
+## Acceptance Criteria
+
+- [ ] `vars/cloudFunctionCICD.groovy` exposes `def call(Map param)` (not the current zero-arg `cloudFunctionCICDFlow()`), accepting at minimum:
+  - `repo_name`
+  - `function_name`
+  - `runtime` — one of `nodejs20` / `python311` / `go121` / etc.
+  - `entry_point`
+  - `region`
+  - `service_account`
+  - `maintainer`
+- [ ] Stages run in this order:
+  1. `checkOut` (reuse `src/com/meesho/stages/checkOut.groovy`)
+  2. Optional: `buildObjHelper.run(param.runtime)` if the runtime needs a transpile/install step (e.g. `node-*` → `npm install && npm run build`). Else skip.
+  3. `gcloud functions deploy ${function_name} --gen2 --runtime ${runtime} --entry-point ${entry_point} --region ${region} --service-account ${service_account} --source .`
+  4. `notify` (reuse `src/com/meesho/stages/notify.groovy`) — same Slack format as `buildPipeline`
+- [ ] Pod selection uses `libraryResource("org/meesho/${env.INFRA_ENV}-pod.yaml")` — never an inline `podTemplate`
+- [ ] Auth: `gcloud` uses ambient Workload Identity via the pod's `service_account`; **no key files written to disk**
+- [ ] Branch gating: only deploy from `master`, `main`, `gcp-main`, or `gcp-master` (match the JFrog/S3 gate in `buildMaven.groovy`) unless `param.deploy_from_any_branch == true`
+- [ ] Deployment-tracker callback fires on success/failure (reuse `notify.groovy:postTrackingApi`)
+- [ ] One real consumer service uses the new entry point end-to-end as the smoke test
+- [ ] `README.md` `## Adding this library to a new service` gains a Cloud Function example block alongside the existing Jenkinsfile sample
+- [ ] `docs/architecture.md` § "Entry points (vars/)" updated — `cloudFunctionCICD` is no longer flagged as "stub"
+- [ ] `BUGS_AND_IMPROVEMENTS_REPORT.md` §1.6 entry is moved to a Resolved section (or struck-through per repo convention)
+- [ ] `docs/index.md` / `docs/wiki/index.md` updated if the entry point gets new dedicated documentation
+
+## Notes / known gotchas
+
+- Use `gcloud functions deploy --gen2` explicitly — gen-1 syntax differs (no `--source .`, different IAM model). Don't write code that works on whichever version happens to be default in the build-tools image.
+- The user-authorization gate from `eksCICD.groovy:12-26` (allowed-users list, Ringmaster banner) is intentionally **not** copied to this entry point unless DevOps says otherwise. Cloud Functions are deployed less frequently; the gate may be overkill.
+- If `runtime` doesn't match a known `buildObjHelper` case (e.g. `python311` vs `python-3.11`), prefer extending the `buildObjHelper` switch to recognise the GCP runtime naming rather than inlining build logic in `cloudFunctionCICD`.
+- This task touches a lot of files (vars/, README, architecture.md, BUGS report) — chunk into reviewable commits if the agent is going autonomous, otherwise one PR is fine.