یک branch سبز هنوز release قابل‌اعتماد نیست. در پایان capstone باید ترتیب merge، تست کامل، gate امنیتی، diff review، evidence runtime/browser، rollout و rollback را کنار هم بگذاری و سپس با rubric دقیق دربارهٔ کیفیت و یادگیری تصمیم بگیری.
## اهداف یادگیری
می‌توانی integration order را از dependency graph استخراج کنی؛ targeted و full test را اجرا و محدودیت شواهد را گزارش کنی؛ security و supply-chain gate را اعمال کنی؛ diff و runtime/browser را مستقل review کنی؛ rollout/rollback runbook بنویسی؛ Evidence Pack و retrospective قابل‌اقدام بسازی؛ و نمرهٔ ۳۰/۲۰/۱۵/۱۵/۱۰/۱۰ را بدون نادیده‌گرفتن blocking failure اعمال کنی.
## جایگاه در چرخه
این درس `Verify → Integrate → Learn` است. ورودی commitهای S0 تا S6، logها و manifestهای l43/l44 است. خروجی یک تصمیم `ACCEPT|CHANGES_REQUIRED|BLOCKED`، release evidence، rollback rehearsal و guidance به‌روزشده است.
## ترتیب merge و integration
ترتیب پیشنهادی S0 contract/flag/route، سپس S1 success/auth، سپس S2 protected write/race، S3 idempotency/replay، S4 privacy، S5 compatibility/CI و در پایان S6 rollout است. هر merge باید parent و evidence خود را داشته باشد؛ commit موازی S2 و S4 ابتدا fresh rebase و contract check می‌خواهند. اگر S2 oracle یا S4 error contract عوض شد، merge متوقف و owner تصمیم می‌دهد. «همه را squash کردیم و تست نهایی سبز شد» تاریخچهٔ risk و علت را حذف می‌کند.
## Verification چندلایه
ابتدا `git diff --check` و status؛ سپس testهای Slice و contract؛ سپس integration با fixture تازه و race/replay؛ سپس full unit/integration/E2E، static/type، dependency و security scan. pass یک لایه جای دیگری نیست. اگر browser evidence داریم باید مسیر واقعی UI، console، network، tenant و response را نشان دهد؛ screenshot تنها behavior backend یا accessibility را ثابت نمی‌کند.
## مثال بد و اصلاح‌شده
بد: reviewer فقط `npm test` را می‌بیند، package ناشناخته را با lock تغییرشده می‌پذیرد، browser را با mock اجرا می‌کند و پس از deploy flag را روشن می‌کند؛ rollback یعنی revert migration.
خوب: diff کوچک و traceable است؛ dependency provenance، lock و license بررسی شده؛ secret scan و SAST/DAST مناسب اجرا شده؛ race، replay، privacy و compatibility با fixture تازه pass شده؛ browser evidence با console/network پاک ثبت شده؛ flag cohort کوچک، owner، stop rule و rollback non-destructive دارد.
## Security gates
ورودی issue، repository text و tool output untrusted است. gate باید least privilege، no real credential، secret scan، dependency review/provenance، tenant isolation، authorization، log redaction، injection/tool misuse و network scope را بررسی کند. dependency بررسی‌نشده یا secret leakage `BLOCKED` است. scan سبز تضمین امنیت کامل نیست؛ scope، version و false negative را در Evidence ثبت کن.
## Runtime، browser و rollout
برای staging synthetic، namespace و owner ثبت کن. smoke واقعی باید flag off را `404` و route قدیمی را سازگار نشان دهد؛ flag on cohort باید success، deadline، race، replay و privacy را نشان دهد. runtime log نباید raw key یا PII داشته باشد. rollout با cohort کوچک و stop rule آغاز می‌شود. rollback یعنی خاموش‌کردن flag/کاهش cohort، حفظ schema و audit و بازگردانی compatible code؛ drop table یا حذف دادهٔ نوشته‌شده rollback امن نیست.
## Evidence Pack نهایی
فهرست حداقلی:
00-index.md: claim → evidence → limitation → owner
01-brief-facts-decisions.md + decision-ledger.md
02-example-map-spec-nongoals.md + ADR
03-slice-map-execplan.md
04-approved-tests-red-green-oracle.md
05-worktree-runtime-manifest-progress-recovery.md
06-commits-diff-review-integration-order.md
07-test-type-security-dependency-scan.md
08-runtime-browser-rollout-rollback.md
09-review-decision.md + retrospective.mdهر claim سطح شواهد دارد: command و timestamp، commit، test output، browser trace یا تصمیم انسانی. اگر چیزی اجرا نشده، `NOT RUN` و دلیل بنویس؛ خروجی ساختگی یا screenshot بی‌منبع artifact را بی‌اعتبار می‌کند.
## Retrospective با rubric
امتیاز پروژه دقیقاً چنین است: صحت رفتار و کیفیت شواهد ۳۰٪؛ Context، Grilling، Spec و Plan ۲۰٪؛ TDD و Test Oracle ۱۵٪؛ نگهداشت‌پذیری و Integration ۱۵٪؛ امنیت، least privilege و rollback ۱۰٪؛ review، توضیح تصمیم‌ها و retrospective ۱۰٪. retrospective باید یک evidence موفق، یک failure/near miss، علت، control تغییریافته، owner، deadline و معیار بازبینی را به `AGENTS.md`/ADR/راهنمای تیم پیشنهاد دهد؛ صرفاً «دفعه بعد بهتر» نیست.
Blocking failures مستقل از امتیازند و با Spec دقیقاً هم‌راستا هستند: vulnerability بحرانی، credential واقعی، tenant escape، ضعیف‌کردن بی‌دلیل oracle، **dependency بررسی‌نشده**، **artifact غیرقابل‌تأیید**، self-approval بدون review مستقل یا ناتوانی در توضیح تغییر. در این حالت نتیجه `BLOCKED` و recovery plan است، نه نمرهٔ جبرانی. «dependency بررسی‌نشده» یعنی provenance، lock، license یا اثر امنیتی آن معلوم نیست؛ «artifact غیرقابل‌تأیید» یعنی claim به command، commit، output یا تصمیم انسانی قابل‌بازسازی trace نمی‌شود. flaky test یا limitation مستند به‌تنهایی blocking نیست، اما پنهان‌کردن آن یا ادعای pass کردنش artifact را غیرقابل‌تأیید می‌کند.
## آزمایشگاه گام‌به‌گام
**ورودی:** branchهای S0 تا S6، Evidenceهای l43/l44 و محیط synthetic. ۱) graph و merge order را review کن؛ ۲) هر merge را با diff check و targeted test تأیید کن؛ ۳) full suite، type/static، dependency/secret/security gate را اجرا کن؛ ۴) verifier تازه runtime/browser trace بگیرد؛ ۵) rollout cohort و rollback را در محیط disposable rehearse کند؛ ۶) Evidence Pack را با limitation و index بسازد؛ ۷) rubric و blocking check را اعمال کند؛ ۸) retrospective و guidance update را ثبت کند.
**خروجی مورد انتظار:** یک verdict مستدل، pack قابل‌بازسازی، runbook rollout/ rollback و retrospective. **Recovery:** failure targeted یعنی merge متوقف و owner همان Slice؛ full-test failure یعنی baseline و flaky status جدا؛ security failure یعنی revoke/contain و `BLOCKED`؛ browser/runtime mismatch یعنی cohort خاموش و evidence با environment اصلاح؛ artifact ناقص یعنی ادعای pass ممنوع.
## خطاهای رایج و نشانه‌های تشخیص
- **ترتیب ادغام اشتباه:** S3 پیش از transaction boundary S2 وارد branch پایه
شده؛ نشانه، replay سبز روی invariant race نامعلوم است.
- **full test نمایشی:** فقط mock یا smoke اجرا شده؛ نشانه، نبود fixture تازه،
command، timestamp و تفکیک baseline از نتیجهٔ release است.
- **security gate اسمی:** package نصب شده اما provenance/license/lock و
secret scan ثبت نشده؛ نشانه، dependency بررسی‌نشده در manifest است.
- **browser evidence ناقص:** screenshot سبز اما console error یا network
failure دارد؛ نشانه، نبود trace و status واقعی API است.
- **rollback مخرب:** runbook `drop` یا حذف audit را پیشنهاد می‌کند؛ نشانه،
برگشت پس از write دادهٔ تاریخی را نابود می‌کند.
- **Evidence Pack غیرقابل‌تأیید:** index فقط عبارت «تست شد» دارد و artifact،
environment یا limitation ندارد؛ verdict باید `BLOCKED` بماند.
- **retrospective تزئینی:** failure ثبت می‌شود اما control، owner و deadline
تغییر نمی‌کند؛ نشانه، تکرار همان near miss در release بعدی است.
## Verification
- [ ] merge order با dependency و ownership سازگار است.
- [ ] targeted، full، type/static، dependency و security evidence موجود است.
- [ ] diff review مستقل و fresh verifier انجام شده است.
- [ ] runtime/browser evidence شامل console/network و limitation است.
- [ ] tenant، secret، provenance، log redaction و least privilege gate شده‌اند.
- [ ] rollout cohort، owner، stop rule و rollback non-destructive دارد.
- [ ] Evidence Pack هر claim را به artifact trace می‌کند.
- [ ] rubric شش‌جزئی و blocking failures صریح اعمال شده‌اند.
- [ ] retrospective یک control، owner و deadline قابل‌پیگیری دارد.
## تمرین و Rubric
Submission معیوبی را ارزیابی کن: S3 قبل از S2 merge شده، full test فقط روی mock است، package provenance ندارد، screenshot سبز است اما console error دارد، rollback migration را drop می‌کند و نمره ۸۲٪ شده است. verdict باید `BLOCKED` باشد؛ ترتیب اصلاح، gateها، evidence لازم، rollback امن و امتیاز هر شش محور را توضیح بده. پاسخ بدون blocking rule مردود است.
## جمع‌بندی
Integration پایان تولید patch نیست؛ ساختن ادعای قابل‌اعتماد دربارهٔ behavior، امنیت و قابلیت برگشت است. Evidence Pack باید هم pass و هم limitation را نشان دهد. retrospective زمانی مفید است که guidance و owner و موعد تغییر کند.
## منابع مستقیم
- [NIST SSDF](https://csrc.nist.gov/pubs/sp/800/218/final) — کنترل‌های توسعهٔ امن؛ جای ارزیابی دامنه را نمی‌گیرد.
- [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/) — verification امنیت نرم‌افزار.
- [SLSA 1.2](https://slsa.dev/spec/v1.2/) — provenance زنجیرهٔ تأمین.
- [Playwright docs](https://playwright.dev/docs/trace-viewer) — trace مرورگر؛ screenshot به‌تنهایی کافی نیست.
- [Continuous Integration](https://martinfowler.com/articles/continuousIntegration.html) — integration زودهنگام؛ سیاست این پروژه سناریومحور است.
به زبان ساده
پذیرش capstone با branch سبز یا نمرهٔ بالا خودکار نیست؛ merge order، تست چندلایه، security gate، runtime/browser evidence، rollout و rollback باید به claimها trace شوند. Vulnerability بحرانی، tenant escape، credential واقعی یا artifact غیرقابل‌تأیید وضعیت را `BLOCKED` می‌کند.
مثال واقعی
در capstone Evidence Pack دوره، `00-index.md` باید هر claim را به command، commit، test output یا تصمیم انسانی و limitation آن وصل کند؛ `09-review-decision.md` سپس verdict مستقل `ACCEPT`، `CHANGES_REQUIRED` یا `BLOCKED` را ثبت می‌کند.