AI ਸਹਿਯੋਗ ਕੈਪਸਟੋਨ: GitHub, Confluence ਅਤੇ Jira

AI ਸਹਿਯੋਗ ਕੋਰਸ ਤੇ ਵਾਪਸ ਜਾਓ

PROP-042 ਦੋ ਵਾਰ ਪੇਸ਼ ਕਰੋ, ਇੱਕ ਵਾਰ GitHub-first ਰਾਹੀਂ ਅਤੇ ਇੱਕ ਵਾਰ Confluence/Jira ਵਾਲੇ GitHub ਰਾਹੀਂ। ਤੁਸੀਂ ਯੋਗਦਾਨ ਪਾਉਂਦੇ ਹੋ, ਵੱਖਰੇ ਮਾਲਕ ਸਮੀਖਿਆ ਕਰਦੇ ਹਨ, ਅਤੇ ਅਧਿਕਾਰਤ ਪ੍ਰਕਾਸ਼ਕ ਬਦਲਾਅ ਲਾਗੂ ਕਰਦੇ ਹਨ। ਪਿਛਲੇ ਪਾਠਾਂ ਤੋਂ ਬਾਅਦ ਵੱਖਰੇ ਸਿੰਥੈਟਿਕ ਸੈਂਡਬਾਕਸ ਵਰਤੋ। ਕੈਪਸਟੋਨ ਸਹਾਇਕ ਦੀ ਲਿਖਤ ਦੀ ਗੁਣਵੱਤਾ ਦੀ ਥਾਂ ਪੂਰੀ ਪ੍ਰਕਿਰਿਆ, ਜਿਸ ਵਿੱਚ ਅਸਵੀਕਾਰਨਾ, ਰਿਕਵਰੀ ਅਤੇ ਸੁਤੰਤਰ ਹੈਂਡਆਫ ਸ਼ਾਮਲ ਹਨ, ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ।

ਮੁੱਖ ਸਿੱਖਣੀਆਂ #

• ਇੱਕ ਸਾਂਝਾ ਬਦਲਾਅ ਦੋਵੇਂ ਅਧਿਕਾਰ ਮਾਡਲਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦਾ ਹੈ।
• ਨਕਾਰਾਤਮਕ ਟੈਸਟ ਸਫਲ ਡਿਲਿਵਰੀ ਜਿੰਨੇ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹਨ।
• ਸਬੂਤ ਪੈਕੇਜ ਸੁਤੰਤਰ ਸਮੀਖਿਆ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।
• ਲੈਬ ਪੂਰੀ ਹੋਣਾ ਪ੍ਰੋਡਕਸ਼ਨ ਰੋਲਆਉਟ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦਾ।

ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ #

ਪੂਰਵ-ਲੋੜਾਂ: ਪਿਛਲੇ ਕੋਰਸ ਮੋਡੀਊਲ , ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਸੈਂਡਬਾਕਸ ਪਹੁੰਚ ਅਤੇ ਵੱਖਰੇ ਸਮੀਖਿਅਕ। ਯੋਜਨਾ ਲਈ ਸਮਾਂ: ਕਈ ਸੈਸ਼ਨਾਂ ਵਿੱਚ ਅੱਠ ਤੋਂ ਬਾਰਾਂ ਘੰਟੇ, ਨਾਲ ਸੁਤੰਤਰ ਸਮੀਖਿਆ। ਅਸਲ ਸਮਾਂ ਖਾਤਾ ਸੈਟਅੱਪ ਅਤੇ ਮੁਰੰਮਤ ਕੰਮ ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਮੁਸ਼ਕਲ: ਉੱਚ।

ਲੋੜੀਂਦੇ ਆਰਟੀਫੈਕਟ: ਚਾਰਟਰ, ਨਕਸ਼ਾ, ਨੀਤੀ, ਐਡਾਪਟਰ, ਬੇਸਲਾਈਨ, ਮੈਨੀਫੈਸਟ, ਤੈਅ ਪ੍ਰਸਤਾਵ, ਮਾਲਕ ਸਮੀਖਿਆਵਾਂ, ਲੈਜਰ, ਰਿਕਵਰੀ ਰਿਕਾਰਡ ਅਤੇ ਹੈਂਡਆਫ। ਯੋਜਨਾ ਤੇ ਨਿਰਭਰ ਗੁੰਮ permissions ਪੂਰਾ ਹੋਣਾ ਰੋਕਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਮੰਨਿਆ ਹੋਇਆ ਪਾਸ ਨਾ ਸਮਝੋ।

ਟੈਸਟਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਟਰੈਕ ਲਈ ਇੱਕ ਸਬੂਤ ਡਾਇਰੈਕਟਰੀ ਤਿਆਰ ਕਰੋ। ਸਮੀਖਿਅਕ ਨੂੰ ਚੈਟ ਸੰਖੇਪ ਤੇ ਨਿਰਭਰ ਹੋਏ ਬਿਨਾਂ actor, source revisions, ਕੀਤੀ ਕਾਰਵਾਈ, ਦੇਖਿਆ ਨਤੀਜਾ ਅਤੇ ਅੰਤਿਮ ਸਥਿਤੀ ਪਛਾਣ ਸਕਣੀ ਚਾਹੀਦੀ ਹੈ।

ਦੋ ਬੇਸਲਾਈਨ ਬਣਾਓ #

1. ਵੱਖਰੇ ਰਨ ਬਣਾਓ ਜਿਨ੍ਹਾਂ ਦੇ ਨਾਮ GitHub-first ਅਤੇ Mixed ਹੋਣ। revisions ਅਤੇ reviews ਵੱਖ ਰੱਖੋ।
2. ਸੱਤ ਦਿਨਾਂ ਦੀ ਬੇਸਲਾਈਨ ਬਹਾਲ ਕਰੋ ਹਰ ਟਰੈਕ ਦੀ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਪ੍ਰਕਿਰਿਆ ਰਾਹੀਂ ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ ਮਿਲੀਆਂ revisions ਕੈਪਚਰ ਕਰੋ।
3. ਅਸਵੀਕਾਰਨਾ ਕੰਟਰੋਲ ਜਾਂਚੋ contributor ਅਤੇ excluded-user ਖਾਤਿਆਂ ਨਾਲ।
4. ਮੌਜੂਦਾ context ਕੈਪਚਰ ਕਰੋ ਅਤੇ adapter/policy ਸਮਝੌਤਾ ਪੱਕਾ ਕਰੋ।
5. ਸਕੋਪ ਘੋਸ਼ਿਤ ਕਰੋ: ਤੀਹ ਦਿਨਾਂ ਦੀ ਸਿੰਥੈਟਿਕ export retention, ਅਸਲ ਡਾਟਾ, backups ਅਤੇ legal holds ਤੋਂ ਬਿਨਾਂ।

PROP-042 correlation label ਹੈ, ਦੁਬਾਰਾ ਵਰਤੀ ਜਾ ਸਕਣ ਵਾਲੀ approval ਨਹੀਂ। ਹਰ run ਨੂੰ ਆਪਣੀ frozen revision ਅਤੇ source evidence ਚਾਹੀਦੀ ਹੈ। ਰਿਪੋਰਟਾਂ ਵਿੱਚ run IDs ਸ਼ਾਮਲ ਕਰੋ।

GitHub-First ਪੇਸ਼ ਕਰੋ #

GitHub lessons ਵਰਤ ਕੇ Issue ਅਤੇ candidate PR ਖੋਲ੍ਹੋ। requirement, configuration, proposal ਅਤੇ runbook ਨੂੰ ਇਕੱਠੇ ਬਦਲੋ। protected base ਕੈਪਚਰ ਕਰੋ, trusted checks ਚਲਾਓ ਅਤੇ final commit ਤੇ product ਅਤੇ operations reviews ਲਵੋ।

Run: GitHub-first
Change: synthetic retention 7 -> 30 days
Requirement: REQ-17 revision 2
Configuration: retention_days 30
Runbook: Retention days: 30
Proposal: base revision 1, from 7, to 30
Manifest: protected pre-change source hashes
Review: product and operations at final proposal revision
Publication: merged commit and read-back
Limit: no running deletion service exercised

ਸੈਂਡਬਾਕਸ ਤੋਂ ਅਸਲ references ਭਰੋ। ਇਹ outline ਉਮੀਦ ਕੀਤੀ mapping ਹੈ, ਪੂਰਾ evidence ਨਹੀਂ। maintainer ਸਿਰਫ review ਤੋਂ ਬਾਅਦ merge ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਸੁਤੰਤਰ ਤੌਰ ਤੇ main ਪੜ੍ਹਦਾ ਹੈ। ਅੰਤਿਮ records ਦੇ links ਜੋੜਨ ਤੋਂ ਬਾਅਦ Issue ਬੰਦ ਕਰੋ।

Mixed ਟਰੈਕ ਪੇਸ਼ ਕਰੋ #

Confluence versions ਪੜ੍ਹੋ ਅਤੇ Jira proposal freeze ਕਰੋ। ਦੋਵੇਂ ਮਾਲਕਾਂ ਦੀਆਂ reviews ਲਵੋ। requirement ਨੂੰ delivery pending ਨਾਲ publish ਕਰੋ, configuration merge ਕਰੋ, runbook publish ਕਰੋ ਅਤੇ Done ਤੋਂ ਪਹਿਲਾਂ ਸਾਰੇ systems ਨੂੰ ਵਾਪਸ ਪੜ੍ਹੋ।

ਹਰ publication ਦਰਜ ਕਰੋ page version, commit ਜਾਂ transition evidence ਨਾਲ। repository requirement copies snapshots ਰਹਿੰਦੀਆਂ ਹਨ। local checker ਮੌਜੂਦਾ Confluence authority ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।

ਮਾਲਕੀ ਦੀਆਂ ਲੋੜਾਂ ਦੇ ਆਧਾਰ ਤੇ workflow ਚੁਣੋ। GitHub-first cross-system coordination ਘਟਾਉਂਦਾ ਹੈ। Mixed track workplace homes ਕਾਇਮ ਰੱਖਦਾ ਹੈ ਅਤੇ publication/access checks ਜੋੜਦਾ ਹੈ।

Failure matrix ਚਲਾਓ #

Cross-system conflict Mixed ਦਾ ਹਿੱਸਾ ਹੈ। GitHub-first ਵਿੱਚ approved file ਨਾਲ ਟਕਰਾਉਂਦੀ Issue description ਟੈਸਟ ਕਰੋ। ਹੋਰ ਲਾਗੂ cases ਦੋਵੇਂ tracks ਵਿੱਚ ਚਲਾਓ। local validator failure live permission evidence ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦੀ।

ਹਰ file ਆਪਣੀ test ਤੋਂ ਪਹਿਲਾਂ ਬਣਾਓ। expected result, observed result, actor role, initial ਅਤੇ final revisions, native evidence reference ਅਤੇ reviewer decision ਦਰਜ ਕਰੋ। browser route prompt direct-push denial ਨਹੀਂ ਹੁੰਦਾ। ਦੋਵੇਂ track directories ਵੱਖ ਰੱਖੋ।

Expected ਅਤੇ observed outcomes ਵੱਖ ਰੱਖੋ। ਹਰ case ਲਈ run ID, actor role, initial revisions, attempted action, expectation, observation, resulting revisions ਅਤੇ reviewer decision ਦਰਜ ਕਰੋ। ਸਾਂਝੀਆਂ ਰਿਪੋਰਟਾਂ ਵਿੱਚ credentials ਅਤੇ account identifiers redaction ਕਰੋ।

Completion ਦਾ ਮੁਲਾਂਕਣ ਕਰੋ #

Pass ਲਈ ਹਰ ਲਾਗੂ row ਦਾ observed evidence ਅਤੇ independent acceptance ਲੋੜੀਂਦੀ ਹੈ। reviewers permissions, source freshness, role review, partial publication, handoff reconstruction ਅਤੇ consistency logs ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ।

ਤੁਰੰਤ Fail ਕਰੋ ਜੇ unauthorized publication, denied text ਦਾ model ਤੱਕ ਪਹੁੰਚਣਾ ਜਾਂ ਬਦਲੇ base ਦਾ silent overwrite ਹੋਵੇ। corrected controls repeat test ਪਾਸ ਕਰਨ ਤੱਕ ਕੰਮ ਨੂੰ Blocked ਰੱਖੋ। ਇਨ੍ਹਾਂ failures ਦਾ ਔਸਤ ਕੱਢ ਕੇ favorable score ਨਾ ਬਣਾਓ।

completed/blocked cases, rejected stale proposals, denied writes, recoveries ਅਤੇ reviewer time ਮਾਪੋ। proposed outcomes observed ਹੋਣ ਤੱਕ expected ਰਹਿੰਦੇ ਹਨ। ਦਿੱਤੇ ਦਸ unit tests consistency ਕਵਰ ਕਰਦੇ ਹਨ, live tenant security ਨਹੀਂ।

ਦੋ runs ਦੀ ਯੋਜਨਾ ਬਣਾਓ #

tracks ਵਿੱਚ approval ਦੁਬਾਰਾ ਨਾ ਵਰਤੋ। requested value ਇੱਕੋ ਹੈ, ਪਰ source homes, captured revisions, permissions ਅਤੇ publishing sequence ਵੱਖ ਹਨ। ਹਰ run ਨੂੰ ਆਪਣੀ evidence directory ਅਤੇ review packet ਦਿਓ।

capstone-evidence/
  github-first/
    charter-and-map
    captured-sources
    fixed-proposal
    role-reviews
    consistency-results
    permission-results
    publication-readback
    recovery-and-handoff
  mixed/
    same evidence categories, independently captured

ਇਹ names organization example ਹਨ, supplied archive files ਨਹੀਂ। ਅਸਲ evidence approved sandbox ਵਿੱਚ private ਰੱਖੋ। shared course submissions ਵਿੱਚ role labels ਅਤੇ redacted references ਵਰਤੋ, ਜਦਕਿ reviewers native records ਤੱਕ ਪਹੁੰਚ ਰੱਖਣ।

failures ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ test observer ਨਿਯੁਕਤ ਕਰੋ। contributor attempted action ਕਰਦਾ ਹੈ। observer initial state, outcome ਅਤੇ resulting state ਦਰਜ ਕਰਦਾ ਹੈ। reviewer ਬਾਅਦ ਵਿੱਚ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ evidence claim ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। independent acceptance ਦਾ ਭਰਮ ਪੈਦਾ ਕਰਨ ਦੀ ਥਾਂ role overlap ਦੱਸੋ।

Failures ਨੂੰ ਅਲੱਗ ਚਲਾਓ #

cases ਦੇ ਵਿਚਕਾਰ verified reviewed state ਤੇ reset ਕਰੋ। source drift, access revocation ਅਤੇ runbook mismatch ਨੂੰ ਇਕੱਠੇ inject ਕਰਨ ਨਾਲ ਕਿਹੜੇ control ਨੇ proposal ਰੱਦ ਕੀਤਾ, ਇਹ ਅਸਪਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ। ਹਰ run ਵਿੱਚ ਇੱਕ failure reviewer ਨੂੰ traceable ਕਾਰਨ ਦਿੰਦਾ ਹੈ।

1. Initial state ਕੈਪਚਰ ਕਰੋ: source revisions, configuration, delivery state ਅਤੇ actor role।
2. ਇੱਕ synthetic injection ਲਗਾਓ: authorized test route ਰਾਹੀਂ ਇੱਕ relevant condition ਬਦਲੋ।
3. bounded action ਕਰੋ: validation, read, publication ਜਾਂ handoff।
4. observation ਦਰਜ ਕਰੋ: actual output ਅਤੇ resulting source state।
5. review ਰਾਹੀਂ repair ਕਰੋ: controls restore ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ failure evidence ਸੰਭਾਲੋ।
6. positive case ਦੁਹਰਾਓ: ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ corrected workflow ਅਜੇ ਵੀ permitted work deliver ਕਰਦਾ ਹੈ।

planned failure ਵੀ failure observation ਹੈ। unauthorized publication ਨੂੰ ਸਿਰਫ਼ ਇਸ ਕਰਕੇ successful test ਨਾ ਕਹੋ ਕਿ ਤੁਸੀਂ ਉਸਨੂੰ probe ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਈ ਸੀ। test ਨੇ defect ਦਿਖਾਉਣ ਵਿੱਚ ਸਫਲਤਾ ਹਾਸਲ ਕੀਤੀ, ਪਰ publication boundary fail ਹੋਈ ਅਤੇ repair ਲੋੜੀਂਦੀ ਹੈ।

ਹਰ case ਲਈ Injection ਅਤੇ reset card: ਅਗਲੀ row ਤੋਂ ਪਹਿਲਾਂ ਨਵਾਂ synthetic proposal ਵਰਤੋ ਜਾਂ reviewed baseline restore ਕਰੋ। observer precondition ਦਰਜ ਕਰਦਾ ਅਤੇ reset ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ। failed attempt ਨੂੰ ledger ਤੋਂ ਕਦੇ ਨਾ ਮਿਟਾਓ।

ਹਰ denied case ਲਈ platform response ਅਤੇ protected record ਦਾ ਦੂਜਾ read ਦਰਜ ਕਰੋ। excluded-user case ਲਈ returned task context ਵੀ inspect ਕਰੋ ਤਾਂ cached excerpt safe denial ਦਾ ਭਰਮ ਨਾ ਬਣੇ। ਜੇ plan ਵਿੱਚ control ਉਪਲਬਧ ਨਹੀਂ ਜਾਂ approved test identity missing ਹੈ, pass simulate ਕਰਨ ਦੀ ਥਾਂ Blocked ਦਰਜ ਕਰੋ।

Mixed ਨਤੀਜੇ ਦੀ ਵਿਆਖਿਆ ਕਰੋ #

Illustrative evidence package: local consistency pass, product ਅਤੇ operations ਨੇ fixed package review ਕੀਤਾ, requirement publication ਸਫਲ ਹੋਈ ਅਤੇ runbook edit access deny ਹੋਈ। configuration ਅਜੇ merge ਨਹੀਂ ਹੋਈ। Jira Blocked ਰਹਿੰਦਾ ਹੈ।

Expected reasoning: run incomplete ਰੱਖੋ, current sources verify ਕਰੋ ਅਤੇ ਢੁਕਵੇਂ owner decision ਦੀ ਮੰਗ ਕਰੋ। permissions ਕਮਜ਼ੋਰ ਕਰਕੇ ਜਾਂ snapshot check ਨੂੰ live publication evidence ਦੱਸ ਕੇ ਖਤਮ ਨਾ ਕਰੋ।

ਭਰਿਆ ਹੋਇਆ mixed-track teaching packet, ਸਿੰਥੈਟਿਕ ਅਤੇ tenant evidence ਨਹੀਂ:

Run: MIXED-042-example
Captured base: REQ-17 v4 = 7 days, RUN-04 v2 = 7 days,
  GitHub main base-001 config.json = {"retention_days": 7}, Jira PROP-042 r1 = In Review
Fixed proposal: REQ-17 v5 wording says synthetic exports 30 days,
  excluding production data, backups, and legal holds.
  GitHub config.json changes retention_days from 7 to 30.
  RUN-04 v3 wording says 30 days, no deletion service runs in this lab,
  and incomplete publication stays pending.
Review: product owner approved the exact requirement wording at PROP-042 r1.
  Operations owner approved the exact config diff and runbook wording at r1.
Publication: publisher reopened REQ-17 v5 and read 30 days.
  Maintainer reopened main at merge-002 and read retention_days 30.
  Publisher reopened RUN-04 v3 and read 30 days.
Denied action: contributor tried an edit to restricted REQ-17 from v5.
  Platform denied the edit, the publisher reread v5 unchanged, and the
  observer saved the native denial. No edit was applied and v5 stayed unchanged.
Recovery: after a separate simulated failed RUN-04 attempt, Jira stayed
  Blocked. Operations approved a retry against the current version.
  Publisher reread v3 after the authorized retry before Jira moved to Done.
Handoff: a new reviewer received MAP-01 and the ledger, reopened the three
  sources and Jira, and named the current 30-day state and remaining runtime gap.
Limit: source publication is shown. Actual deletion timing is Not run.

ਹਰ illustrative version, actor, denial ਅਤੇ read-back ਨੂੰ live row Supported ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ native records ਨਾਲ ਬਦਲੋ। ਜੇ ਕੋਈ plan ਜਾਂ role test ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦਾ, row ਨੂੰ Blocked ਦਰਜ ਕਰੋ ਅਤੇ ਦੋਵੇਂ track ਵਾਲਾ course incomplete ਰੱਖੋ।

Independent reader ਨਾਲ review ਕਰੋ #

reviewer ਨੂੰ events reconstruct ਕਰਨ ਲਈ ਕਹੋ, ਸਿਰਫ਼ ਆਪਣਾ conclusion ਪੜ੍ਹਨ ਲਈ ਨਹੀਂ। ਤੁਹਾਡੀ narration ਤੋਂ ਬਿਨਾਂ ਉਹ approved baseline, fixed proposal, owner decisions, resulting revisions, failed attempts, repair ਅਤੇ remaining gaps ਲੱਭ ਸਕਣ।

Reviewer questions:
Which source governs retention intent in this track?
Which exact package did each owner review?
Did any source change after review?
What was published, and what remains pending?
Which denied action was observed under which role?
Did protected text reach an excluded user's context?
Which repair was reviewed and read back?
Does the fresh handoff reconstruct current state independently?

ਹਰ requirement ਨੂੰ ਵੱਖਰੇ score ਕਰੋ। evidence reference ਨਾਲ Supported, Failed, Blocked ਜਾਂ Not run ਵਰਤੋ। consistency, approval, permissions, recovery ਅਤੇ handoff ਵੱਖ requirements ਹਨ। green local tests ਦਾ ਸਮੂਹ failed live publication boundary ਨੂੰ offset ਨਹੀਂ ਕਰਦਾ।

Run ID and track:
Reviewer role and review date:
Case 01 approved change: status ___ evidence ___ gap ___
Case 02 stale context: status ___ evidence ___ gap ___
Case 03 unauthorized write: status ___ evidence ___ gap ___
Case 04 conflict: status ___ evidence ___ gap ___
Case 05 partial publication: status ___ evidence ___ gap ___
Case 06 access denial: status ___ evidence ___ gap ___
Case 07 recovery: status ___ evidence ___ gap ___
Case 08 handoff: status ___ evidence ___ gap ___
Overall decision: Supported / Failed / Blocked / Not run
Next accountable role and action:

Supported ਦਾ ਅਰਥ ਹੈ ਕਿ reviewer ਨੇ ਹਰ ਲਾਗੂ case ਲਈ observed evidence ਲੱਭ ਲਿਆ। observed control failure ਲਈ Failed, missing access ਜਾਂ missing control ਲਈ Blocked ਅਤੇ unattempted case ਲਈ Not run ਦਰਜ ਕਰੋ। ਹਰ case ਦਾ native reference ਉਸਦੀ named evidence file ਵਿੱਚ ਰੱਖੋ।

Course pass gate: GitHub-first ਅਤੇ Mixed ਦੋਵੇਂ tracks ਪੂਰੇ ਕਰੋ। ਹਰ track ਵਿੱਚ ਉੱਪਰਲੇ ਸਾਰੇ ਅੱਠ ਲਾਗੂ cases ਨੂੰ Supported evidence ਚਾਹੀਦਾ ਹੈ। Failed boundary ਜਾਂ missing native read-back track ਨੂੰ block ਕਰਦਾ ਹੈ। missing paid plan ਜਾਂ test identity Blocked ਦਿੰਦੇ ਹਨ, guessed pass ਨਹੀਂ। ਇੱਕ ਪੂਰਾ track documented partial result ਦਿੰਦਾ ਹੈ, course completion ਨਹੀਂ।

Redacted model package, ਕੇਵਲ ਉਦਾਹਰਨ ਲਈ:

Track: github-first | Run: G-01 | Reviewer: separate pilot role
Base: protected commit base-001 | Fixed proposal: PROP-042 r1
Approvals: product review ref P-01, operations review ref O-01
Consistency: local check pass, saved output ref C-01
Permission: contributor direct push denied, native event ref D-01
Publication: merged commit merge-002, fresh clone confirms thirty
Exception: backups and legal holds remain excluded
Recovery: interruption case R-01 read back and resolved through review
Handoff: second reader found current base, exception, and next action
Runtime limit: no production deletion or deployment claim
Decision: Supported for synthetic GitHub-first track only

ਹਰ illustrative reference ਨੂੰ observed sandbox artifact ਨਾਲ ਬਦਲੋ। Mixed track ਲਈ ਇਸਦਾ ਆਪਣਾ source versions ਅਤੇ reviews ਵਾਲਾ ਪੂਰਾ package ਦੁਹਰਾਓ। reviewer ਨੂੰ Mixed package ਵਿੱਚ copied GitHub approval ਰੱਦ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਸੀਮਿਤ ਫੈਸਲਾ ਲਿਖੋ #

ਉਪਯੋਗੀ closing decision ਅਗਲੇ pilot ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ, unrestricted rollout ਦਾ ਨਹੀਂ। ਉਦਾਹਰਨ ਲਈ ਉਹੀ roles ਅਤੇ direct lookup route ਵਰਤਦਿਆਂ ਹੋਰ synthetic export setting ਚੁਣੋ, ਜਦਕਿ real data ਅਤੇ automated publication ਨੂੰ scope ਤੋਂ ਬਾਹਰ ਰੱਖੋ।

Completion check: ਦੋਵੇਂ run packages independent reconstruction ਤੋਂ ਬਚੇ ਰਹਿਣ, ਲਾਗੂ failure cases ਲਈ observed evidence ਹੋਵੇ ਅਤੇ unresolved controls ਦਿਖਦੇ ਰਹਿਣ। ਜੇ ਸਿਰਫ਼ GitHub track ਪੂਰਾ ਹੈ, ਤਾਂ partial course completion report ਕਰੋ। Mixed track ਵੀ ਅਜਿਹਾ ਹੀ ਵਰਤੇਗਾ, ਇਹ ਨਾ ਮੰਨੋ।

Troubleshooting ਅਤੇ Backout #

ਸਿਰਫ਼ happy-path evidence: denial ਅਤੇ interruption tests ਦੁਬਾਰਾ ਚਲਾਓ। Overlapping roles: ਦੱਸੋ ਅਤੇ ਵੱਖਰੇ users ਨਾਲ ਦੁਹਰਾਓ। Missing plan controls: ਰੁਕੋ ਅਤੇ approved sandbox ਲਵੋ।

Backout: reviewed PRs ਅਤੇ Confluence edits ਰਾਹੀਂ baseline ਬਹਾਲ ਕਰੋ, temporary integrations revoke ਕਰੋ, Jira evidence archive ਕਰੋ ਅਤੇ evidence retention ਤੋਂ ਬਾਅਦ owner-approved synthetic cleanup ਕਰੋ। recovery history ਸੰਭਾਲੋ।

Rollout decision ਬਣਾਓ #

Decision: another synthetic pilot, blocked, or rejected
Evidence: both run packages and failure matrix
Unenforced requirements: procedural controls listed explicitly
Provider review: input scope and retention handling
Owner coverage: product, operations, policy, repository, delivery
Production gaps: runtime tests, secrets, deployment, access review
Next action: one bounded follow-up with accountable role
Review date: assigned by pilot owners

Expected reasoning: synthetic success another bounded pilot ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ। Production ਲਈ real data, deployment, provider handling ਅਤੇ runtime behavior ਲਈ ਵੱਖਰੀ approval ਚਾਹੀਦੀ ਹੈ। successful assistant answer deployment authorization ਨਹੀਂ ਹੈ।

ਮੁੱਖ references #

• Repository controls: Protected branches ।
• Workplace access: Confluence permissions ।
• Delivery controls: Jira permission schemes ।

ਅਗਲੇ ਕਦਮ #

course hub ਤੇ ਵਾਪਸ ਜਾਓ ਅਤੇ missing controls ਦੀ ਸਮੀਖਿਆ ਕਰੋ। ਹੋਰ pilot ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀ implementation ਦੀ framework article ਨਾਲ ਤੁਲਨਾ ਕਰੋ।