ਸਿਆਣਾ ਡਿਵੈਲਪਰ ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ ’ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

ਇੱਕ ਸਿਆਣਾ ਡਿਵੈਲਪਰ «ਕੋਡਿੰਗ ਸ਼ੁਰੂ ਕਰਕੇ ਉਮੀਦ» ਨਹੀਂ ਕਰਦਾ। ਉਹ ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ ਨੂੰ brainstorming, ਟੀਮ ਚਰਚਾ, ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ, ਡਾਇਗਰਾਮ, ਪ੍ਰਸਤਾਵ, ADR, MR/PR ਅਤੇ GitOps ਰਾਹੀਂ ਲਿਜਾਂਦੇ ਹਨ — Review Bot ਆਪਣੇ ਆਪ PR ਟਿੱਪਣੀਆਂ ਬਣਾਉਂਦੇ ਹਨ ਤਾਂ ਜੋ ਇਨਸਾਨ ਮਹੱਤਵਪੂਰਨ ਗੱਲਾਂ ’ਤੇ ਸਮਾਂ ਲਗਾਣ। ਇਹੀ production-grade playbook ਹੈ। FDE ਸਿਸਟਮ ਖੜਾ ਕਰ ਸਕਦਾ ਹੈ; Claude Architect Certification ਲਾਇਕ ਹੈ ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਡਿਜ਼ਾਈਨ ਤੇ ਬਚਾਅ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।

1. ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ ’ਤੇ «ਸਿਆਣਾ» ਦਾ ਅਰਥ

ਸਿਆਣਪ ਵੱਧ ਮੀਟਿੰਗਾਂ ਨਹੀਂ। ਇਹ ਜਲਦੀ ਸਸਤਾ ਸਿੱਖਣਾ ਅਤੇ ਦੇਰ ਦੀਆਂ ਮਹਿੰਗੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਦੁਰਲੱਭ ਬਣਾਉਣਾ ਹੈ। ਹੇਠਾਂ ਕ੍ਰਮ ਇਸ ਤਰ੍ਹਾਂ ਹੈ ਕਿ ਹਰ ਕਦਮ ਅਗਲੇ ਦੇ blast radius ਨੂੰ ਘਟਾਏ:

Brainstorm → Discuss → Prototype → Diagram → Propose → ADR
        → Implement in small slices → MR/PR + Review Bot → Merge
        → GitOps promote (dev → staging → prod) → Observe → Iterate

ਕਦਮ ਸਿਰਫ਼ ਇਰਾਦੇ ਨਾਲ ਛੱਡੋ (ਜਿਵੇਂ ਇੱਕ-ਲਾਈਨ config fix)। Production ਪਹੁੰਚ ਸਕਣ ਵਾਲੀ ਕਿਸੇ ਵੀ ਚੀਜ਼ ’ਤੇ Review Bot + CI ਕਦੇ ਨਾ ਛੱਡੋ।

2. Brainstorming (ਪਹਿਲਾਂ ਇਕੱਲੇ, ਫਿਰ ਢਾਂਚਾਬੱਧ)

ਕਿਸੇ ਤੋਂ ਸਮਾਂ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ 30–90 ਮਿੰਟ ਇਕੱਲੇ ਲਗਾਓ:

• ਨਤੀਜਾ: ਖਤਮ ਹੋਣ ’ਤੇ ਕਿਹੜਾ ਯੂਜ਼ਰ/ਕਾਰੋਬਾਰ ਬਦਲਾਅ ਸੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ?
• ਪਾਬੰਦੀਆਂ: ਸਮਾਂ, ਬਜਟ, compliance, ਮੌਜੂਦਾ ਪਲੇਟਫਾਰਮ, ਟੀਮ ਹੁਨਰ।
• ਗੈਰ-ਲਕਸ਼: v1 ਵਿੱਚ ਅਸੀਂ ਕੀ ਨਹੀਂ ਬਣਾਵਾਂਗੇ (scope ਰੱਖਦਾ ਹੈ)।
• ਖਤਰੇ: ਡਾਟਾ, ਸੁਰੱਖਿਆ, ਪ੍ਰਦਰਸ਼ਨ, vendor lock-in, ਓਪਰੇਸ਼ਨਲ ਲੋਡ।
• ਸਫਲਤਾ ਮੈਟ੍ਰਿਕਸ: latency, error rate, adoption, cost — ਦੋ ਚੁਣੋ ਜੋ ਮਹੱਤਵਪੂਰਨ ਹਨ।

ਇਸ ਨੂੰ ਛੋਟੀ ਨੋਟ ਵਿੱਚ ਲਿਖੋ (Notion/Confluence/ਰੈਪੋ ਵਿੱਚ docs/ideas/ markdown)। ਲਿਖਤੀ artifact ਤੋਂ ਬਿਨਾਂ brainstorming ਸਿਰਫ਼ ਗੱਲਬਾਤ ਹੈ ਜੋ ਉੱਡ ਜਾਂਦੀ ਹੈ।

3. ਸਹਿਕਰਮੀਆਂ ਨਾਲ ਚਰਚਾ

ਸਭ ਤੋਂ ਛੋਟਾ ਲਾਭਦਾਇਕ ਘੇਰਾ ਸੱਦੋ: ਇੱਕ peer ਜੋ ਤੁਹਾਡੇ ਨਾਲ implement ਕਰੇਗਾ, ਨਾਲ ਲੱਗਦੇ ਸਿਸਟਮ ਦਾ ਮਾਲਕ, ਅਤੇ (ਲੋੜ ’ਤੇ) security ਜਾਂ SRE। ਸਿਆਣਪ ਰੱਖਣ ਵਾਲੇ ਨਿਯਮ:

• Time-box (25–45 ਮਿੰਟ)। ਫੈਸਲਿਆਂ ਜਾਂ ਖੁੱਲ੍ਹੇ ਸਵਾਲਾਂ ’ਤੇ ਖਤਮ ਕਰੋ — vibes ਨਹੀਂ।
• ਵਿਕਲਪਾਂ ’ਤੇ ਅਸਹਿਮਤੀ, ਲੋਕਾਂ ’ਤੇ ਨਹੀਂ। «option A vs B vs defer» ਲਾਗੂ ਕਰੋ।
• ਇੱਕ scribe ਨਿਯੁਕਤ ਕਰੋ। ਨੋਟ ਪ੍ਰਸਤਾਵ ਦਾ ਬੀਜ ਬਣਦੀ ਹੈ।
• ਚੁੱਪ veto ਨਹੀਂ। ਜੇ ਕੋਈ ਅਸਹਿਜ ਹੈ, ਬਾਅਦ ਵਿੱਚ ADR ਵਿੱਚ ਚਿੰਤਾ ਨੂੰ ਖਤਰਾ ਲਿਖੋ।

Async ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ: ਛੋਟਾ RFC ਕਮੈਂਟ ਥ੍ਰੈਡ ਅਕਸਰ ਮੀਟਿੰਗ ਤੋਂ ਵਧੀਆ — ਪਰ ਕਿਸੇ ਨੂੰ ਲੂਪ ਬੰਦ ਕਰਨਾ ਹੀ ਪਵੇਗਾ।

4. ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ (ਮਿਆਦ ਵਾਲੇ spikes)

ਅਨਿਸ਼ਚਿਤਤਾ ਉੱਚੀ ਹੋਵੇ ਤਾਂ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰੋ: ਨਵਾਂ API, ਅਣਜਾਣ ਕਲਾਉਡ ਸੇਵਾ, ਪ੍ਰਦਰਸ਼ਨ ਸਵਾਲ, ਜਾਂ AI/agent ਵਿਵਹਾਰ। ਸਿਆਣੇ ਨਿਯਮ:

1. ਟਿਕਟ ਵਿੱਚ ਇਸ ਨੂੰ spike ਨਾਮ ਦਿਓ; ਕੈਲੰਡਰ stop ਸੈੱਟ ਕਰੋ (ਆਮ ਤੌਰ ’ਤੇ 1–3 ਦਿਨ)।
2. ਕੋਡ throwaway ਬ੍ਰਾਂਚ ਜਾਂ spikes/ ਫੋਲਡਰ ਵਿੱਚ ਰੱਖੋ; polish ਨਾ ਕਰੋ।
3. 10 ਬੁਲੈਟ ਵਿੱਚ ਸਿੱਖਿਆ ਲਿਖੋ — ਖਾਸਕਰ ਜੋ ਫੇਲ ਹੋਇਆ।
4. ਫੈਸਲਾ: promote (ਉਤਪਾਦ ਵਿੱਚ refactor), rewrite, ਜਾਂ abandon।

ਬਿਨਾਂ ADR ਚੁੱਪਚਾਪ production ਬਣਨ ਵਾਲੇ ਪ੍ਰੋਟੋਟਾਈਪ ਟੀਮਾਂ ਨੂੰ accidental architecture ਵਿਰਾਸਤ ਵਿੱਚ ਦਿੰਦੇ ਹਨ।

5. ਡਾਇਗਰਾਮ (ਬਹਿਸ ਲਈ ਕਾਫ਼ੀ)

UML ਨਾਵਲ ਦੀ ਲੋੜ ਨਹੀਂ। ਤਿੰਨ ਸਕੈਚ ਚੁਣੋ ਜੋ ਹਰ ਇੱਕ ਇੱਕ ਸਕ੍ਰੀਨ ’ਤੇ ਫਿੱਟ ਹੋਣ:

ਡਾਇਗਰਾਮ	ਜਵਾਬ ਦਿੰਦਾ ਹੈ
Context (C4 L1)	ਕੌਣ ਕਿਸ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ? Trust boundaries?
Sequence	Happy path + ਇੱਕ failure path
Deployment	ਕਿੱਥੇ ਚੱਲਦਾ ਹੈ; config ਤੇ secrets ਕਿਵੇਂ ਵਗਦੇ ਹਨ

Mermaid ਜਾਂ ਚਿੱਤਰ ਪ੍ਰਸਤਾਵ ਕੋਲ ਰੱਖੋ (docs/architecture/)। ADR ਬਦਲਣ ’ਤੇ ਡਾਇਗਰਾਮ ਅੱਪਡੇਟ ਕਰੋ — ਪੁਰਾਣੀਆਂ ਤਸਵੀਰਾਂ ਨਾ ਹੋਣ ਤੋਂ ਮਾੜੀਆਂ ਹਨ।

6. ਪ੍ਰਸਤਾਵ (ਹਲਕਾ RFC)

ਚੰਗਾ ਪ੍ਰਸਤਾਵ ਇੱਕ ਤੋਂ ਤਿੰਨ ਪੰਨੇ:

1. ਸਮੱਸਿਆ ਅਤੇ ਹੁਣ ਕਿਉਂ
2. ਵਿਚਾਰੇ ਵਿਕਲਪ (ਘੱਟੋ-ਘੱਟ ਦੋ)
3. ਸਿਫ਼ਾਰਸ਼ ਅਤੇ ਕਿਉਂ
4. ਪ੍ਰਭਾਵ: ਸੁਰੱਖਿਆ, ਲਾਗਤ, ops, migration
5. Rollout ਤੇ rollback
6. ਖੁੱਲ੍ਹੇ ਸਵਾਲ

ਸਪੱਸ਼ਟ deadline ਨਾਲ review ਮੰਗੋ। ਮਨਜ਼ੂਰੀ (ਜਾਂ ਸੋਧਾਂ ਸਹਿਤ) ’ਤੇ ਫੈਸਲੇ ਨੂੰ ADR ਬਣਾਓ — «source of truth» ਚੈਟ ਵਿੱਚ ਨਾ ਛੱਡੋ।

7. ADR — Architecture Decision Records

ADR ਫੈਸਲੇ ਦਾ ਛੋਟਾ, convention ਅਨੁਸਾਰ ਅਟੱਲ ਰਿਕਾਰਡ ਹੈ। ਟੈਮਪਲੇਟ:

# ADR-00XX: Title

Status: Proposed | Accepted | Superseded by ADR-00YY
Date: YYYY-MM-DD
Deciders: @alice @bob

## Context
What forces are in play?

## Decision
What we will do.

## Consequences
Positive, negative, and follow-ups.

## Alternatives considered
Option A — why not
Option B — why not

ADR git ਵਿੱਚ ਰੱਖੋ (docs/adr/)। PR ਤੋਂ ਲਿੰਕ ਕਰੋ। ਇਤਿਹਾਸ rewrite ਕਰਨ ਬਜਾਏ supersede ਕਰੋ — ਭਵਿੱਖ ਦੇ ਤੁਹਾਨੂੰ trail ਚਾਹੀਦੀ ਹੈ।

8. MR ਅਤੇ PR — delivery ਦੀ ਇਕਾਈ

MR (Merge Request, GitLab) ਅਤੇ PR (Pull Request, GitHub/Bitbucket) ਇੱਕੋ ਵਿਚਾਰ ਹਨ: reviewable change set। ਸਿਆਣੀਆਂ ਆਦਤਾਂ:

• ਛੋਟਾ: ਆਦਰਸ਼ ਤੌਰ ’ਤੇ meaningful diff <400 ਲਾਈਨਾਂ; vertical slices ਵਿੱਚ ਵੰਡੋ।
• ਇੱਕ intent: ਇੱਕ feature, fix, ਜਾਂ chore — «misc» ਨਹੀਂ।
• ਵੇਰਵਾ: ਕਿਉਂ, ਕਿਵੇਂ ਟੈਸਟ ਕਰਨਾ, screenshots/logs, ਖਤਰਾ, rollback।
• ਲਿੰਕ: ticket + ADR + design diagram।
• ਪਹਿਲਾਂ Draft ਜਦੋਂ ਜਲਦੀ ਫੀਡਬੈਕ ਚਾਹੀਦਾ ਹੋਵੇ ਬਿਨਾਂ «ready to merge» ਦਾ ਇਸ਼ਾਰਾ।
• ਕਦੇ force-merge ਨਾ ਕਰੋ ਲਾਲ CI ਜਾਂ ਨਾ-ਹੱਲ ਹੋਏ high-severity bot findings ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਿਨਾਂ ਲਿਖਤੀ exception।

ਉਦਾਹਰਨ PR body checklist

## Summary
- …

## Test plan
- [ ] Unit tests
- [ ] Manual path …
- [ ] Feature flag / config …

## Risk & rollback
- Risk: …
- Rollback: revert this PR / GitOps revert commit …

## References
- ADR-00XX
- Ticket ABC-123

9. Review Bot ਵਰਤੋਂ — ਆਟੋ-ਤਿਆਰ PR ਟਿੱਪਣੀਆਂ

Review Bot ਆਟੋਮੈਟਿਕ reviewer ਹੈ ਜੋ ਹਰ MR/PR ’ਤੇ inline ਟਿੱਪਣੀਆਂ ਤੇ ਸਾਰ ਪੋਸਟ ਕਰਦਾ ਹੈ। ਇਹ ਇਨਸਾਨਾਂ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ; ਉਬਾਊ ਤੇ ਖ਼ਤਰਨਾਕ ਨੂੰ ਅੱਗੇ ਲਿਆਉਂਦਾ ਹੈ।

9.1 Bot ਨੂੰ ਕਿਸ ’ਤੇ ਟਿੱਪਣੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ

• Security: injection, authz ਖਾਲੀਆਂ, secret leakage, ਅਸੁਰੱਖਿਤ defaults
• Correctness: null paths, race conditions, ਟੁੱਟੇ migrations
• Tests: ਨਵੀਆਂ ਬ੍ਰਾਂਚਾਂ ’ਤੇ missing coverage, snapshot ਦੀ ਦੁਰਵਰਤੋਂ
• API/contract: ਬਿਨਾਂ version bump breaking changes
• Ops: missing timeouts, ਬਿਨਾਂ idempotency, unbounded retries
• Style ਸਿਰਫ਼ ਜਦੋਂ formatter/linter ਤੋਂ ਬਚ ਨਿਕਲਿਆ ਹੋਵੇ (ਸ਼ੋਰ ਤੋਂ ਬਚੋ)

9.2 ਡਿਵੈਲਪਰ ਜੀਵਨ ਕਿਵੇਂ ਸੌਖਾ ਬਣਦਾ ਹੈ

1. ਲੇਖਕ PR ਖੋਲ੍ਹਦਾ ਹੈ → bot ਸਕਿੰਟਾਂ ਤੋਂ ਮਿੰਟਾਂ ਵਿੱਚ ਚੱਲਦਾ ਹੈ।
2. ਲੇਖਕ ਇਨਸਾਨ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ bot ਥ੍ਰੈਡ ਠੀਕ ਕਰਦਾ ਜਾਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।
3. ਮਨੁੱਖੀ reviewer bot ਸਾਰ ਪੜ੍ਹਦਾ ਹੈ + ਡਿਜ਼ਾਈਨ ਤੇ ਉਤਪਾਦ ਖਤਰੇ ’ਤੇ ਧਿਆਨ ਦਿੰਦਾ ਹੈ।
4. ਘੱਟ «nit» ਰਾਊਂਡ; ਤੇਜ਼ merge; ਖੁੰਝੇ footguns ਤੋਂ ਘੱਟ ਸ਼ੁੱਕਰਵਾਰ-ਰਾਤ ਘਟਨਾਵਾਂ।

9.3 ਆਮ setup ਵਿਕਲਪ

ਪਹੁੰਚ	ਨੋਟਸ
SaaS Review Bot (ਜਿਵੇਂ CodeRabbit, vendor bots)	ਤੇਜ਼ੀ ਨਾਲ ਚਾਲੂ; severity ਤੇ path ਫਿਲਟਰ ਟਿਊਨ ਕਰੋ
Cursor Bugbot / IDE-ਲਿੰਕਡ review	Cursor-ਕੇਂਦਰਿਤ ਟੀਮਾਂ ਵਿੱਚ PR diffs ’ਤੇ ਮਜ਼ਬੂਤ
Custom GitHub Action + Claude / LLM	ਪੂਰਾ ਨਿਯੰਤਰਣ; prompt + policy + cost caps ਚਾਹੀਦੇ
ਪਰਤਾਂ ਵਾਲੀ pipeline (lint → SAST → LLM)	ਸਭ ਤੋਂ ਵਧੀਆ production posture — AI code review pipeline ਗਾਈਡ ਵੇਖੋ

9.4 ਨੀਤੀ ਜੋ bot ਨੂੰ ਲਾਭਦਾਇਕ ਰੱਖੇ

• Severity ਲੇਬਲ: blocker / should-fix / nit — nits merge ਨਾ ਰੋਕਣ।
• Generated paths ਅਣਡਿੱਠੇ ਕਰੋ (vendor/, lockfiles ਸ਼ੋਰ, protobuf dumps)।
• Security-sensitive paths (auth/, infra/, IAM) ’ਤੇ ਮਨੁੱਖੀ approval ਲਾਜ਼ਮੀ।
• False positives ਲਾਗ ਕਰੋ; ਮਹੀਨਾਵਾਰ ignore ਨਿਯਮਾਂ ਵਿੱਚ ਵਾਪਸ ਪਾਓ।
• Production-critical ਸੇਵਾਵਾਂ ’ਤੇ bot ਨੂੰ ਕਦੇ ਇਕੱਲਾ reviewer ਨਾ ਬਣਾਓ।

9.5 ਘੱਟੋ-ਘੱਟ GitHub Action ਸਕੈਚ

# .github/workflows/review-bot.yml
name: review-bot
on:
  pull_request:
    types: [opened, synchronize, reopened]
jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Run Review Bot
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
        run: |
          # Fetch diff, call your review CLI, post review comments via gh api
          ./scripts/review-bot.sh

review-bot.sh ਲਾਗੂ ਕਰੋ: PR diff ਕੱਢੋ, ਸਖ਼ਤ system prompt (security + correctness ਪਹਿਲਾਂ) ਨਾਲ ਮਾਡਲ ਕਾਲ ਕਰੋ, ਅਤੇ GitHub/GitLab API ਨਾਲ ਟਿੱਪਣੀਆਂ ਪੋਸਟ ਕਰੋ। Token ਸੀਮਿਤ ਕਰੋ; ਲਾਗਤ ਚਿੰਤਾ ਹੋਵੇ ਤਾਂ drafts ਛੱਡੋ।

10. Production-grade ਗੁਣਵੱਤਾ ਲਈ GitOps ਵਧੀਆ ਅਭਿਆਸ

GitOps ਦਾ ਅਰਥ: desired state git ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ; reconciler (Argo CD, Flux ਆਦਿ) ਕਲੱਸਟਰ ਮਿਲਾਉਂਦਾ ਹੈ; promotion ਇੱਕ merge ਹੈ; rollback ਇੱਕ revert ਹੈ।

• App code ਤੇ env config ਵੱਖ ਕਰੋ (ਜਾਂ ਸਾਫ਼ ਫੋਲਡਰ: apps/ vs envs/dev|staging|prod)।
• Prod ’ਤੇ kubectl apply ਨਹੀਂ happy path ਵਜੋਂ — ਸਿਰਫ਼ break-glass, audited।
• Progressive delivery: dev ’ਤੇ auto-sync; prod ਲਈ manual ਜਾਂ gated sync।
• Image digests prod manifests ਵਿੱਚ mutable tags ਤੋਂ ਵਧੀਆ।
• Policy as code: OPA/Kyverno ਅਧਿਕਾਰ, registries, resource limits ਲਈ।
• Signed commits / provenance ਜਿੱਥੇ ਤੁਹਾਡਾ threat model ਮੰਗਦਾ ਹੈ।
• Sync ਤੋਂ ਬਾਅਦ observe ਕਰੋ: health checks, error budgets, ਤਿਆਰ ਹੋਣ ’ਤੇ automatic rollback hooks।

ਕੋਡ ਗੁਣਵੱਤਾ ਸਿਰਫ਼ «ਸਾਫ਼ ਫੰਕਸ਼ਨ» ਨਹੀਂ। ਇਹ ਵੀ ਹੈ ਬਦਲਾਅ production ਵਿੱਚ ਕਿਵੇਂ ਆਉਂਦਾ ਹੈ। GitOps ਉਸ ਰਾਹ ਨੂੰ reviewable, reversible ਤੇ repeatable ਬਣਾਉਂਦਾ ਹੈ।

11. End-to-end quality gates (production ਲਈ ਅਨੁਕੂਲ)

Local:     pre-commit (fmt, lint, secrets) + unit tests
PR open:   CI (build, test, SAST) + Review Bot comments
PR merge:  human approve + branch protection + required checks
Main:      build immutable artifact (image digest)
GitOps:    update env repo / overlay → sync → verify
Prod:      SLOs + alerts + runbook linked from ADR/PR

12. FDE ਭੂਮਿਕਾ — ਇਹ ਸਿਸਟਮ ਕੌਣ ਸੈੱਟ ਕਰਦਾ ਹੈ

Forward Deployed Engineer ਅਸਲ ਟੀਮ ਵਿੱਚ ਸਿਆਣੇ-ਡਿਵੈਲਪਰ ਸਿਸਟਮ ਲਗਾਉਣ ਲਈ ਆਦਰਸ਼ ਹੈ:

• Repo ਟੈਮਪਲੇਟ: docs/adr/, PR ਟੈਮਪਲੇਟ, CODEOWNERS, branch protection
• Review Bot + secrets + ਲਾਗਤ ਨਿਯੰਤਰਣ
• CI required checks ਤੇ environment protections
• GitOps apps (dev/staging/prod) ਤੇ promotion docs
• ਦੋ-ਹਫ਼ਤੇ coaching: ਪਹਿਲਾ ADR, ਪਹਿਲਾ bot-tuned PR, ਪਹਿਲਾ GitOps rollback drill

ਇੱਕ product repo ’ਤੇ FDE-ਅਗਵਾਈ enablement ਲਈ ਸੰਕੇਤਕ ਕੈਲੰਡਰ: scaffolding ਤੇ bot policy ਲਈ 1–2 ਹਫ਼ਤੇ; GitOps promotion path ਤੇ dry-run rollback ਲਈ +1–2 ਹਫ਼ਤੇ। ਸਭਿਆਚਾਰ ਬਦਲਾਅ ਲੰਬਾ ਲੈਂਦਾ ਹੈ — merge time ਤੇ escaped defects ਮਾਪੋ, tool installs ਨਹੀਂ।

13. Claude Architect Certification — ਲਾਇਕ

ਜੇ ਤੁਸੀਂ ਐਸੇ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹੋ ਜਿੱਥੇ ਇਨਸਾਨ ਤੇ AI ਏਜੰਟ ਰਲ਼ ਕੇ ਕੋਡ ਲਿਖਦੇ ਹਨ, Claude Architect Certification ਲਾਇਕ ਹੈ। ਇਹ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ:

• ਮਾਡਲ ਨੂੰ ਗਲਤੀ-ਰਹਿਤ ਨਾ ਮੰਨਦੇ ਹੋਏ AI-assisted delivery ਆਰਕੀਟੈਕਟ ਕਰ ਸਕਦੇ ਹੋ
• Agentic workflows ਲਈ review ਨੀਤੀਆਂ, guardrails ਤੇ evaluation ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹੋ
• Stakeholders ਨੂੰ trade-offs (latency, cost, privacy, accuracy) ਸਮਝਾ ਸਕਦੇ ਹੋ
• AI ਟੂਲਾਂ ਨਾਲ ADR, PR ਅਨੁਸ਼ਾਸਨ ਤੇ production gates ’ਤੇ ਟੀਮਾਂ ਨੂੰ coach ਕਰ ਸਕਦੇ ਹੋ

Credential ਨੂੰ ਅਸਲ delivery ਨਾਲ ਜੋੜੋ: Review Bot ਖੜਾ ਕਰੋ, ਤਿੰਨ ADR ਲਿਖੋ, GitOps rollback drill ਚਲਾਓ। ਅਭਿਆਸ ਤੋਂ ਬਿਨਾਂ ਕਾਗਜ਼ ਸਿਆਣਾ ਨਹੀਂ ਬਣਾਉਂਦਾ; ਅਭਿਆਸ ਪਲੱਸ ਸਾਂਝੀ ਭਾਸ਼ਾ ਬਣਾਉਂਦੀ ਹੈ।

14. Anti-patterns (ਬੇਸਮਝੀ ਕਿਵੇਂ ਦਿਖਦੀ ਹੈ)

• «WIP please approve ASAP» ਵਾਲੀ ਵਿਸ਼ਾਲ PR
• ਆਰਕੀਟੈਕਚਰ ਸਿਰਫ਼ Slack ਵਿੱਚ ਫੈਸਲਾ, ਕਦੇ ADR ਵਿੱਚ ਨਹੀਂ
• ਬਿਨਾਂ ਟੈਸਟ ਪ੍ਰੋਟੋਟਾਈਪ prod ਵਿੱਚ merge
• Review Bot ਬੰਦ ਕਿਉਂਕਿ «ਇਹ ਪਰੇਸ਼ਾਨ ਕਰਦਾ ਹੈ»
• ਬਿਨਾਂ revert ਯੋਜਨਾ GitOps ਤੋਂ ਬਾਹਰ prod hotfix
• ਇਨਸਾਨ ਉਹੀ formatter nits ਦੁਹਰਾਉਂਦੇ ਹਨ ਜੋ bot ਪਹਿਲਾਂ ਫੜ ਚੁੱਕਿਆ

15. ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ ਲਈ copy-paste starter checklist

1. docs/ideas/, docs/architecture/, docs/adr/ ਬਣਾਓ
2. PR/MR ਟੈਮਪਲੇਟ + CODEOWNERS ਜੋੜੋ
3. pre-commit + CI required checks ਚਾਲੂ ਕਰੋ
4. Review Bot ਇੰਸਟਾਲ ਕਰੋ; path ਫਿਲਟਰ ਤੇ severities ਟਿਊਨ ਕਰੋ
5. ADR-0001 ਲਿਖੋ: «We use GitOps for deploy»
6. Environments ਤੇ promotion ਨਿਯਮ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ
7. 30-ਮਿੰਟ rollback game day ਤਹਿ ਕਰੋ
8. ਪਹਿਲੇ ਮਹੀਨੇ coaching ਲਈ FDE ਸਮਾਂ ਬੁੱਕ ਕਰੋ; ਲੀਡਾਂ ਲਈ Claude Architect Certification ਵਿਚਾਰੋ

16. ਸਮਾਪਤੀ

ਇੱਕ ਸਿਆਣਾ ਡਿਵੈਲਪਰ ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਸਿੱਖਣ ਦੇ artifacts ਦੀ ਲੜੀ ਮੰਨਦਾ ਹੈ — ਨੋਟਸ, ਡਾਇਗਰਾਮ, ਪ੍ਰਸਤਾਵ, ADR — ਫਿਰ Review Bot ਦੀ ਨਿਗਰਾਨੀ ਤੇ GitOps ਦੀ ਪ੍ਰਮੋਸ਼ਨ ਨਾਲ ਛੋਟੇ MR/PR ਰਾਹੀਂ ਡਿਲੀਵਰ ਕਰਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਕੋਡ ਗੁਣਵੱਤਾ production grade ਲਈ ਅਨੁਕੂਲ ਹੁੰਦੀ ਹੈ ਬਿਨਾਂ ਟੀਮ ਨੂੰ ਅਨੰਤ nits ’ਤੇ ਸਾੜੇ। FDE ਨੂੰ ਰੇਲ ਲਗਾਉਣ ਦਿਓ; ਪ੍ਰਮਾਣਿਤ ਆਰਕੀਟੈਕਟ ਸਿਸਟਮ ਈਮਾਨਦਾਰ ਰੱਖਣ ਜਦੋਂ AI ਕੋਡ ਲਿਖਣ ਦੀ ਗਤੀ ਵਧਾਉਂਦਾ ਹੈ।

ਪ੍ਰਕਾਸ਼ਿਤ Workstation.