GitHub, Confluence ਅਤੇ Jira ਵਿੱਚ AI ਪ੍ਰਕਾਸ਼ਨ ਵਰਕਫਲੋ

AI ਸਹਿਯੋਗ ਕੋਰਸ ਵੱਲ ਵਾਪਸ ਜਾਓ

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

ਮੁੱਖ ਗੱਲਾਂ #

• ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਮਨੋਰਥ ਅਤੇ ਦਿੱਤਾ ਗਿਆ ਵਿਹਾਰ ਵੱਖਰੇ ਹਨ।
• ਨਿਸ਼ਚਿਤ ਪ੍ਰਸਤਾਵ ਰਿਵਿਜ਼ਨ ਸਮੀਖਿਆ ਨੂੰ ਖਾਸ ਵਰਜਨ ਨਾਲ ਜੋੜਦੇ ਹਨ।
• ਪ੍ਰਕਾਸ਼ਨ ਲੇਜਰ ਅਧੂਰੇ ਕੰਮ ਨੂੰ ਦਿਖਾਉਂਦੇ ਹਨ।
• ਤਾਜ਼ਾ ਪੜ੍ਹਤਾਂ ਬਦਲੇ ਹੋਏ ਆਧਾਰ ਤੋਂ ਬਚਾਉਂਦੀਆਂ ਹਨ।

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

ਲੋੜਾਂ: ਕਾਰਜ-ਥਾਂ ਸੈਟਅੱਪ , ਪ੍ਰਕਾਸ਼ਨ ਪਹੁੰਚ, ਮਾਲਕ ਅਤੇ ਰਿਪੋਜ਼ਟਰੀ ਰੱਖ-ਰਖਾਅਕਰਤਾ। ਅੰਦਾਜ਼ਨ ਸਮਾਂ: ਦੋ ਘੰਟੇ। ਮੁਸ਼ਕਲ: ਉੱਨਤ ਤਾਲਮੇਲ।

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

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

ਮੌਜੂਦਾ ਸਰੋਤ ਦਰਜ ਕਰੋ #

1. MAP-01 ਪੜ੍ਹੋ, ਫਿਰ ਮੈਪ ਕੀਤੇ ਪੇਜ ID ਨਾਲ REQ-17 ਅਤੇ RUN-04 ਖੋਲ੍ਹੋ।
2. ਪੇਜ ਮੀਨੂ ਅਤੇ Page History ਖੋਲ੍ਹੋ, ਫਿਰ ਅੰਕੀ ਵਰਜਨ, ਸਥਿਤੀ, ਲਿਖਤ, ਮਾਲਕ ਅਤੇ ਅਪਵਾਦ ਦਰਜ ਕਰੋ।
3. Jira ਆਈਟਮ ਪੜ੍ਹੋ ਅਤੇ ਪ੍ਰਸਤਾਵ ਦਾ ਨਿਸ਼ਚਿਤ ਐਕਸਪੋਰਟ ਜਾਂ GitHub commit ਜੋੜੋ। ਸਿਰਫ਼ ਕੁੰਜੀ ਸਮੀਖਿਆ ਸਬੂਤ ਨੂੰ ਸਥਿਰ ਨਹੀਂ ਕਰਦੀ।
4. ਮਨਜ਼ੂਰਸ਼ੁਦਾ POL-01 ਅਤੇ ਸੁਰੱਖਿਅਤ ਕਨਫਿਗਰੇਸ਼ਨ ਆਧਾਰ ਪੜ੍ਹੋ।
5. ਚੈਟ ਨੂੰ ਸਿਰਫ਼ ਲੋੜੀਂਦੇ ਕ੍ਰਿਤ੍ਰਿਮ ਅੰਸ਼ ਦਿਓ, ਉਹਨਾਂ ਨੂੰ ਸਨੈਪਸ਼ਾਟ ਵਜੋਂ ਚਿੰਨ੍ਹੋ ਅਤੇ ਲਿਖਣ-ਯੋਗ ਕਾਰਵਾਈਆਂ ਬੰਦ ਰੱਖੋ।

Task: PROP-042, propose only
Authority: Confluence REQ-17 for intent, GitHub for behavior
Read: mapped current pages, versions, scope, exceptions
Proposal: synthetic export retention from 7 to 30 days
Output: requirement wording, config diff, runbook, ledger
Evidence: source ID and captured revision for each factual claim
Unknowns: missing access and absent runtime observations
Stop: conflict, changed base, or denied access

ਆਫਲਾਈਨ ਪੈਕੇਟ ਸਨੈਪਸ਼ਾਟ-ਆਧਾਰਿਤ ਰਹਿੰਦੇ ਹਨ। ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਕਾਸ਼ਕ ਮੌਜੂਦਾ ਸਰੋਤ ਮੁੜ ਪੜ੍ਹਦਾ ਹੈ। ਪਹੁੰਚ ਨਾ ਮਿਲਣ ਨਾਲ ਪ੍ਰਕਾਸ਼ਨ ਰੁਕਦਾ ਹੈ। ਪੁਰਾਣਾ ਐਕਸਪੋਰਟ ਮੌਜੂਦਾ ਅਧਿਕਾਰ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ।

ਪ੍ਰਸਤਾਵ ਸਥਿਰ ਕਰੋ #

{
  "proposal_id": "PROP-042",
  "proposal_revision": 1,
  "requirement_base_version": 1,
  "runbook_base_version": 1,
  "policy_version": 1,
  "from_days": 7,
  "to_days": 30,
  "status": "awaiting-owner-review",
  "publication_order": ["requirement", "implementation", "runbook", "delivery"]
}

ਦਿਖਾਵੇ ਲਈ ਦਿੱਤੇ ਪੇਜ ਵਰਜਨਾਂ ਦੀ ਥਾਂ ਅਸਲ ਵਿੱਚ ਦਰਜ ਕੀਤੇ ਵਰਜਨ ਵਰਤੋ। ਨਿਸ਼ਚਿਤ JSON ਅਤੇ ਪ੍ਰਸਤਾਵਿਤ ਲਿਖਤ Jira ਨਾਲ ਜੋੜੋ। ਹਰ ਮਾਲਕ ਆਪਣੀ ਭੂਮਿਕਾ, ਫੈਸਲਾ, ਪ੍ਰਸਤਾਵ ਰਿਵਿਜ਼ਨ, ਸਰੋਤ ਵਰਜਨ ਅਤੇ ਸਮੀਖਿਆ ਦਾ ਸਮਾਂ ਦਰਜ ਕਰਦਾ ਹੈ। ਕੋਈ ਵੀ ਅਹਿਮ ਸੋਧ ਪੈਕੇਜ ਨੂੰ Review ਵੱਲ ਵਾਪਸ ਭੇਜਦੀ ਹੈ।

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

ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ ਅਤੇ ਮੁੜ ਪੜ੍ਹੋ #

1. ਜਦੋਂ ਪ੍ਰਕਾਸ਼ਕ ਦੋਵੇਂ ਮਾਲਕਾਂ ਦੀਆਂ ਸਮੀਖਿਆਵਾਂ ਅਤੇ ਅਣਬਦਲੇ ਸਰੋਤ-ਆਧਾਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਲਵੇ, Jira ਨੂੰ Publishing ਵਿੱਚ ਲਿਜਾਓ।
2. REQ-17 ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ, ਤੀਹ ਦਿਨ ਅਤੇ ਡਿਲਿਵਰੀ-ਬਕਾਇਆ ਖੇਤਰ ਸਮੇਤ। ਬਣਿਆ ਵਰਜਨ, ਦਾਇਰਾ ਅਤੇ ਅਪਵਾਦ ਦਰਜ ਕਰੋ।
3. GitHub ਲਾਗੂਕਰਨ PR ਖੋਲ੍ਹੋ, ਮਨਜ਼ੂਰ ਪੇਜ ਵਰਜਨ ਦਾ ਹਵਾਲਾ ਦਿਓ। ਕਨਫਿਗਰੇਸ਼ਨ ਨੂੰ ਤੀਹ ਦਿਨ ਕਰੋ ਅਤੇ ਗੈਰ-ਅਧਿਕਾਰਤ ਲੋੜ-ਸਨੈਪਸ਼ਾਟ ਜੋੜੋ।
4. ਰਿਪੋਜ਼ਟਰੀ ਸਮੀਖਿਆ ਮਗਰੋਂ ਮਰਜ ਕਰੋ ਅਤੇ main ਮੁੜ ਪੜ੍ਹੋ। ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਦਰਜ ਵਿਹਾਰ ਨੂੰ ਰਨਟਾਈਮ ਵਿਹਾਰ ਤੋਂ ਵੱਖਰਾ ਦਰਜ ਕਰੋ।
5. RUN-04 ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ, ID ਨਾਲ ਮੁੜ ਪੜ੍ਹੋ ਅਤੇ ਬਣਿਆ ਵਰਜਨ ਦਰਜ ਕਰੋ। ਪ੍ਰਕਾਸ਼ਕ ਲੋੜ ਦੇ ਡਿਲਿਵਰੀ ਹਵਾਲੇ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ।
6. Jira ਤਦ ਹੀ ਪੂਰਾ ਕਰੋ ਜਦੋਂ ਸਾਰੇ ਰਿਕਾਰਡ ਮਿਲਣ ਅਤੇ ਅੰਤਿਮ ਮੁੜ-ਪੜ੍ਹਤ ਦਾ ਸਬੂਤ ਜੁੜਿਆ ਹੋਵੇ।

ਸਥਾਨਕ ਵੈਲੀਡੇਟਰ ਨੂੰ ਸਿਰਫ਼ ਸਨੈਪਸ਼ਾਟ ਦੀ ਇਕਸਾਰਤਾ ਲਈ ਵਰਤੋ। ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਦੀ Confluence ਲੋੜ ਨੂੰ ਲੈਬ ਦੇ ਆਧਾਰ JSON ਸਕੀਮਾ ਵਿੱਚ ਕਾਪੀ ਕਰੋ, ਕੈਪਚਰ ਕਰੋ ਅਤੇ ਉਮੀਦਵਾਰ ਨੂੰ ਤੀਹ ਦਿਨ ਵਿੱਚ ਬਦਲੋ। Jira ਵਿੱਚ ਅਸਲ Confluence ਵਰਜਨ ਵੱਖਰੇ ਰੱਖਦਿਆਂ ਸਥਾਨਕ ਸਨੈਪਸ਼ਾਟ ਰਿਵਿਜ਼ਨ ਵਧਾਓ। GitHub-ਪਹਿਲਾਂ ਵਾਲਾ ਮੂਲ-ਸਰੋਤ ਵਰਕਫਲੋ ਲਾਈਵ Confluence ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰਦਾ। ਇਸਦੀ ਹਰੀ ਸਥਿਤੀ ਨੂੰ ਬਾਹਰੀ ਅਧਿਕਾਰ ਦੀ ਪੁਸ਼ਟੀ ਨਾ ਦੱਸੋ।

ਇਸ ਅਭਿਆਸ ਵਿੱਚ ਮਿਟਾਉਣ ਦੀ ਕਾਰਜ-ਸਮਰੱਥਾ ਡਿਪਲੌਇ ਨਾ ਕਰੋ। ਅਸਲ ਸੇਵਾ ਲਈ ਡਿਪਲਾਇਮੈਂਟ ਸਬੂਤ, ਨਿਯੰਤਰਿਤ ਟੈਸਟ ਡਾਟਾ, ਹੋਲਡ ਪ੍ਰਬੰਧ ਅਤੇ ਰਨਟਾਈਮ-ਸੀਮਾ ਟੈਸਟ ਲੋੜੀਂਦੇ ਹਨ। ਮਰਜ ਰਿਪੋਜ਼ਟਰੀ ਦੀ ਸਥਿਤੀ ਸਾਬਤ ਕਰਦਾ ਹੈ, ਉਤਪਾਦਨ ਵਿੱਚ ਰਿਟੈਨਸ਼ਨ ਵਿਹਾਰ ਨਹੀਂ।

ਅੰਸ਼ਕ ਪ੍ਰਕਾਸ਼ਨ ਦਰਜ ਕਰੋ #

ਅਗਲਾ ਕਦਮ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਨਤੀਜਾ ਲਿਖੋ। PROP-042 ਵੱਖਰੇ ਸਿਸਟਮਾਂ ਦੀਆਂ ਘਟਨਾਵਾਂ ਜੋੜਦਾ ਹੈ। ਇੱਕ ਪੂਰੀ ਕਤਾਰ ਦਾ ਮਤਲਬ ਪੂਰਾ ਬਦਲਾਅ ਨਹੀਂ।

ਨਾਕਾਮੀ ਦੀ ਮਿਸਾਲ: Confluence ਤੀਹ ਦਿਨ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਪਰ GitHub ਮਰਜ ਰੋਕਦਾ ਹੈ। Jira ਨੂੰ Blocked ਰੱਖੋ ਅਤੇ ਲੋੜ ਨੂੰ ਡਿਲਿਵਰੀ-ਬਕਾਇਆ ਚਿੰਨ੍ਹੋ। ਪ੍ਰੋਡਕਟ ਟੀਮ ਅੱਗੇ ਕੰਮ ਪੂਰਾ ਕਰਨ ਜਾਂ ਸਮੀਖਿਆ ਮਗਰੋਂ ਸੱਤ ਦਿਨ ਵਾਪਸ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰਦੀ ਹੈ। ਐਮਰਜੈਂਸੀ README ਕਾਪੀ ਨੂੰ ਲੋੜ ਦਾ ਅਧਿਕਾਰਤ ਸਰੋਤ ਨਾ ਬਣਾਓ।

ਇਕੱਠੇ ਹੋਏ ਸੋਧਾਂ ਨੂੰ ਸੰਭਾਲੋ #

ਬ੍ਰਾਊਜ਼ਰ ਆਧਾਰ: ਪਾਇਲਟ ਸਮੇਂ ਲਈ ਇੱਕ ਪ੍ਰਕਾਸ਼ਕ ਨਿਯੁਕਤ ਕਰੋ। ਸੋਧ ਤੋਂ ਤੁਰੰਤ ਪਹਿਲਾਂ ਅਤੇ ਪ੍ਰਕਾਸ਼ਨ ਤੋਂ ਬਾਅਦ Page History ਮੁੜ ਖੋਲ੍ਹੋ। ਹੋਰ ਲੇਖਕ ਸਰੋਤ ਬਦਲੇ ਤਾਂ ਰੁਕੋ, ਤੁਲਨਾ ਕਰੋ, ਮਿਲਾਪ ਕਰੋ ਅਤੇ ਮਨਜ਼ੂਰੀ ਨਵੀਂ ਲਵੋ। ਕ੍ਰਮਵਾਰ ਪ੍ਰਕਾਸ਼ਨ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਹੈ, ਐਟਾਮਿਕ ਲੈਣ-ਦੇਣ ਦੀ ਗਰੰਟੀ ਨਹੀਂ।

API ਵਿਸਥਾਰ: Confluence v2 ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ GET /wiki/api/v2/pages/{id}?body-format=storage ਅਤੇ ਵਰਜਨ ਆਬਜੈਕਟ ਵਾਲਾ PUT /wiki/api/v2/pages/{id} ਦਿੱਤਾ ਹੈ। ਸਮੀਖਿਆ ਕੀਤਾ ਪ੍ਰਕਾਸ਼ਕ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਮੌਜੂਦਾ ਵਰਜਨ ਦੀ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਆਧਾਰ ਨਾਲ ਤੁਲਨਾ ਕਰਦਾ ਹੈ, ਅਗਲਾ ਵਰਜਨ ਭੇਜਦਾ ਹੈ ਅਤੇ ਮੁੜ ਪੜ੍ਹਦਾ ਹੈ। ਨਾਕਾਮ ਵਰਜਨ ਨੂੰ ਆਪਣੇ ਆਪ ਰਿਫ੍ਰੈਸ਼ ਕਰਕੇ ਪੁਰਾਣਾ ਬਾਡੀ ਮੁੜ ਨਾ ਭੇਜੋ।

ਸਿਰਫ਼ API ਦੀ ਸਫਲਤਾ ਕਾਫ਼ੀ ਨਹੀਂ। ਬਣਿਆ ਸਮੱਗਰੀ, ਸਰੋਤ ID, ਦਾਇਰਾ ਅਤੇ ਵਰਜਨ ਜਾਂਚੋ। ਇਸ ਕੋਰਸ ਵਿੱਚ ਲਿਖਣ-ਯੋਗ API ਕਲਾਇੰਟ ਨਹੀਂ ਹੈ। ਕੋਡ ਨਾ ਲਿਖਣ ਵਾਲਿਆਂ ਲਈ ਮਨੁੱਖ ਵੱਲੋਂ ਬ੍ਰਾਊਜ਼ਰ ਪ੍ਰਕਾਸ਼ਨ ਚੱਲਣਯੋਗ ਆਧਾਰ ਹੈ।

ਨਕਾਰਾਤਮਕ ਮਾਮਲੇ ਜਾਂਚੋ #

ਸੈਂਡਬਾਕਸ ਦੇ ਅਸਲ ਨਤੀਜੇ ਕਾਰਜਕਰਤਾ ਦੀ ਭੂਮਿਕਾ ਅਤੇ ਪਹਿਲਾਂ/ਬਾਅਦ ਦੇ ਰਿਵਿਜ਼ਨ ਨਾਲ ਦਰਜ ਕਰੋ। ਇਨਕਾਰ ਕੀਤੇ ਵਰਤੋਂਕਾਰ ਦੇ ਸਬੂਤ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਪੇਜ ਬਾਡੀ ਨਾ ਰੱਖੋ। ਉਮੀਦਿਤ ਨਤੀਜੇ ਮਾਪੇ ਹੋਏ ਨਤੀਜੇ ਨਹੀਂ ਹਨ।

ਸਮੀਖਿਆ ਪੈਕੇਜ ਬਣਾਓ #

ਸਿਰਫ਼ ਪ੍ਰਸਤਾਵ ਦਾ ਲੇਬਲ ਨਹੀਂ, ਸਮੱਗਰੀ ਸਥਿਰ ਕਰੋ। PROP-042 ਹਰ ਸਿਸਟਮ ਵਿੱਚ ਦਿਖਦਾ ਹੈ, ਪਰ ਲੇਬਲ ਉਹ ਬਾਡੀ ਨਹੀਂ ਦੱਸਦਾ ਜਿਸਦੀ ਮਾਲਕ ਨੇ ਸਮੀਖਿਆ ਕੀਤੀ। ਸਹੀ ਲੋੜ-ਲਿਖਤ, ਲਾਗੂਕਰਨ diff, ਰਨਬੁੱਕ ਲਿਖਤ, ਸਰੋਤ ਵਰਜਨ ਅਤੇ ਪ੍ਰਕਾਸ਼ਨ ਕ੍ਰਮ ਇੱਕ ਨਿਸ਼ਚਿਤ ਪੈਕੇਜ ਵਿੱਚ ਰੱਖੋ।

Package: PROP-042 revision 1, illustrative
Intent: synthetic export retention changes from 7 to 30 days
Exclusions: production data, backups, legal holds
Requirement amendment: fixed proposed REQ-17 wording
Implementation: fixed candidate diff and protected base reference
Runbook amendment: fixed RUN-04 wording and recovery limits
Review: product and operations decisions for this package
Delivery: requirement -> implementation -> runbook -> closure
Stop: changed source, missing review, denied write, failed read-back

ਪੈਕੇਟ ਦੋਵੇਂ ਮਾਲਕਾਂ ਲਈ ਪੜ੍ਹਨਯੋਗ ਰੱਖੋ। ਪ੍ਰੋਡਕਟ ਨੂੰ ਮਨੋਰਥ ਅਤੇ ਬਾਹਰ ਰੱਖੀਆਂ ਚੀਜ਼ਾਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਓਪਰੇਸ਼ਨਜ਼ ਨੂੰ ਕਾਰਜ-ਬਦਲਾਅ ਅਤੇ ਬਹਾਲੀ ਦੀ ਹੱਦ ਚਾਹੀਦੀ ਹੈ। ਮਨਜ਼ੂਰ ਮਨੋਰਥ ਅਤੇ ਦਿੱਤੀ ਕਨਫਿਗਰੇਸ਼ਨ ਵੱਖਰੀ ਹੋਣ ਦਾ ਸਮਾਂ ਦੋਵੇਂ ਸਮਝਣ। ਰਿਪੋਜ਼ਟਰੀ ਫਾਈਲਾਂ ਨਾਲ ਅਣਜਾਣ ਮਾਲਕ ਲਈ ਸਿਰਫ਼ ਕੋਡ diff ਕਾਫ਼ੀ ਨਹੀਂ।

ਇਸ ਕ੍ਰਿਤ੍ਰਿਮ ਮਿਸਾਲ ਲਈ ਭਰਿਆ ਪੈਕੇਜ:

REQ-17 proposed v5: "Synthetic export files are retained for 30 days from creation. This pilot excludes production data, backups, and legal holds. Delivery remains pending until the GitHub configuration and RUN-04 read-backs match this approved wording."

GitHub config.json, proposed change against base-001:
-  "retention_days": 7
+  "retention_days": 30

RUN-04 proposed v3: "Retention days: 30. Synthetic exports only. No deletion job runs in this lab. If publication fails, keep delivery pending, read back each source, and obtain owner approval before restoring the seven-day configuration or completing the thirty-day publication."

ਇਹ ਲਿਖਤ ਉਦਾਹਰਣੀ ਪ੍ਰਸਤਾਵ ਹੈ, ਲਾਈਵ ਟੈਨੈਂਟ ਰਿਕਾਰਡ ਨਹੀਂ। ਸਮੀਖਿਆ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲ ਆਧਾਰ commit ਅਤੇ ਪੇਜ ਵਰਜਨ ਜੋੜੋ। ਨਿਸ਼ਚਿਤ ਪੈਕੇਜ ਵਿੱਚ ਪੂਰੀ ਪ੍ਰਸਤਾਵਿਤ ਲਿਖਤ ਹੋਵੇ, ਅਜਿਹਾ ਸਾਰ ਨਹੀਂ ਜਿਸ ਤੋਂ ਮਾਲਕ ਨੂੰ ਆਪਣੇ ਆਪ ਅਰਥ ਕੱਢਣਾ ਪਵੇ।

ਆਫਲਾਈਨ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਲਾਈਵ ਪ੍ਰਕਾਸ਼ਨ ਵੱਖਰੇ ਰੱਖੋ। ਪਹਿਲੀ ਲਿਖਤ ਤੋਂ ਤੁਰੰਤ ਪਹਿਲਾਂ ਪ੍ਰਕਾਸ਼ਕ ਮੈਪ ਕੀਤੇ ਪੇਜ ਮੁੜ ਜਾਂਚਦਾ ਹੈ ਅਤੇ ਰੱਖ-ਰਖਾਅਕਰਤਾ ਸੁਰੱਖਿਅਤ ਆਧਾਰ ਮੁੜ ਜਾਂਚਦਾ ਹੈ। ਕੋਈ ਵੀ ਬਦਲਿਆ ਹੋਵੇ ਤਾਂ ਪੁਰਾਣਾ ਪੈਕੇਜ Review ਉੱਤੇ ਰੁਕਦਾ ਹੈ।

ਲੇਜਰ ਅਨੁਸਾਰ ਚੱਲੋ #

ਉਦਾਹਰਣੀ ਸਥਿਤੀ-ਤਰੱਕੀ: ਸਾਰਣੀ ਵਿੱਚ ਸਿਖਲਾਈ ਵਾਲੇ ਰਿਵਿਜ਼ਨ ਹਨ, ਅਸਲ ਨਿਰੀਖਣ ਨਹੀਂ। ਹਰ ਸੈਂਡਬਾਕਸ ਲਿਖਤ ਮਗਰੋਂ ਅਸਲ ਨਤੀਜਾ ਵਰਜਨ ਅਤੇ commit ਭਰੋ।

ਡਿਲਿਵਰੀ ਬਕਾਇਆ ਇੱਕ ਅਰਥਪੂਰਨ ਸਥਿਤੀ ਹੈ। ਇਹ ਅਧੂਰੇ ਪ੍ਰਕਾਸ਼ਨ ਦੌਰਾਨ ਪੁਰਾਣੇ ਲਾਗੂਕਰਨ ਨੂੰ ਨਵੇਂ ਮਨੋਰਥ ਨਾਲ ਅਨੁਕੂਲ ਦੱਸਣ ਤੋਂ ਰੋਕਦੀ ਹੈ। ਇਸ ਸਮੇਂ ਪਾਠਕਾਂ ਨੂੰ ਦੋਵੇਂ ਮੁੱਲ ਚਾਹੀਦੇ ਹਨ, ਇਹ ਇਕੱਲਾ ਸਾਰ ਨਹੀਂ ਕਿ ਰਿਟੈਨਸ਼ਨ ਤੀਹ ਦਿਨ ਹੈ।

ਨਾਕਾਮ ਕੋਸ਼ਿਸ਼ਾਂ ਵੱਖਰੀਆਂ ਘਟਨਾਵਾਂ ਵਜੋਂ ਜੋੜੋ। ਰਨਬੁੱਕ ਲਿਖਤ ਨਾਕਾਮ ਹੋਵੇ ਤਾਂ ਲੋੜ ਅਤੇ ਕਨਫਿਗਰੇਸ਼ਨ ਦੇ ਸਫਲ ਨਤੀਜੇ ਰੱਖੋ। ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਕਾਰਵਾਈ, ਨਾਕਾਮੀ, ਨਾ ਬਦਲਿਆ ਵਰਜਨ, ਸੌਂਪੀ ਭੂਮਿਕਾ ਅਤੇ ਅਗਲਾ ਕਦਮ ਦਰਜ ਕਰੋ। ਪੂਰੀਆਂ ਕਤਾਰਾਂ ਨੂੰ Pending ਉੱਤੇ ਵਾਪਸ ਨਾ ਕਰੋ ਅਤੇ ਵੇਖਿਆ ਕ੍ਰਮ ਨਾ ਮਿਟਾਓ।

ਪੁਰਾਣੇ ਵਰਜਨ ਦੇ ਇਨਕਾਰ ਦੀ ਮਿਸਾਲ: ਪ੍ਰਕਾਸ਼ਕ REQ-17 v4 ਪੜ੍ਹਦਾ ਹੈ, ਹੋਰ ਅਧਿਕਾਰਤ ਸੰਪਾਦਕ v5 ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਫਿਰ ਪ੍ਰਕਾਸ਼ਕ v4 ਉੱਤੇ PROP-042 r1 ਲਾਗੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਪਲੇਟਫਾਰਮ ਵਰਜਨ ਟਕਰਾਅ ਦਿਖਾਉਂਦਾ ਹੈ ਜਾਂ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਪੜ੍ਹਤ v5 ਵੇਖਦੀ ਹੈ। ਕਾਰਜਕਰਤਾ publisher, ਸ਼ੁਰੂਆਤੀ v4, ਕੋਸ਼ਿਸ਼ PROP-042 r1, ਵੇਖਿਆ ਟਕਰਾਅ ਜਾਂ ਬਦਲਿਆ ਮੌਜੂਦਾ ਵਰਜਨ, ਇਸ ਕੋਸ਼ਿਸ਼ ਨਾਲ ਨਾ ਬਦਲਿਆ ਅੰਤਿਮ v5, ਅਤੇ ਸੌਂਪਿਆ ਮਾਲਕ product owner ਦਰਜ ਕਰੋ। Jira ਨੂੰ Review ਵਿੱਚ ਰੱਖੋ। v5 ਮੁੜ ਪੜ੍ਹੋ, ਲਿਖਤ ਮਿਲਾਓ ਅਤੇ ਹੋਰ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਨਵੇਂ ਨਿਸ਼ਚਿਤ ਪੈਕੇਜ ਦੀ ਸਮੀਖਿਆ ਮੰਗੋ। ਲਾਈਵ ਟੈਸਟ ਵਿੱਚ ਅਸਲ ਪਲੇਟਫਾਰਮ ਜਵਾਬ ਅਤੇ Page History ਵਰਤੋ। ਇਹ ਕਤਾਰ ਸਿਖਲਾਈ ਦੀ ਮਿਸਾਲ ਹੈ।

ਪੂਰੀ ਸਿਖਲਾਈ ਮਿਸਾਲ, ਕ੍ਰਿਤ੍ਰਿਮ ਮੁੱਲ ਹੀ:

ਉਪਰਲੇ ਲੇਬਲ ਉਦਾਹਰਣ ਹਨ, ਟੈਨੈਂਟ ਸਬੂਤ ਨਹੀਂ। ਤੁਹਾਡੇ ਲੇਜਰ ਨੂੰ ਮੂਲ ਪੇਜ-ਵਰਜਨ ਲਿੰਕ ਅਤੇ commit ID ਚਾਹੀਦੇ ਹਨ। Jira ਨੂੰ Done ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਮਾ ਪ੍ਰਸਤਾਵ, ਦੋਵੇਂ ਭੂਮਿਕਾ-ਸਮੀਖਿਆਵਾਂ, ਸਰੋਤ-ਆਧਾਰ ਰਿਕਾਰਡ, ਹਰ ਪ੍ਰਕਾਸ਼ਨ ਦੀ ਮੁੜ-ਪੜ੍ਹਤ, ਨਕਾਰਾਤਮਕ ਟੈਸਟ ਨਤੀਜਾ ਅਤੇ ਬਾਕੀ ਰਨਟਾਈਮ ਸੀਮਾਵਾਂ ਜੋੜੋ। ਕੋਈ ਚੀਜ਼ ਗੁੰਮ ਹੋਵੇ ਤਾਂ ਡਿਲਿਵਰੀ ਖੁੱਲ੍ਹੀ ਜਾਂ Blocked ਰੱਖੋ।

ਪੈਕੇਜ ਗੇਟ: ਪੰਜਾਂ ਜਾਂਚਾਂ ਨੂੰ Supported ਜਾਂ Blocked ਚਿੰਨ੍ਹੋ: ਸਰੋਤ ਰਿਵਿਜ਼ਨ ਤਾਜ਼ੇ ਹਨ, ਦੋਵੇਂ ਮਾਲਕਾਂ ਨੇ ਇੱਕੋ ਨਿਸ਼ਚਿਤ ਰਿਵਿਜ਼ਨ ਮਨਜ਼ੂਰ ਕੀਤਾ, ਸਭ ਲੋੜੀਂਦੇ ਪ੍ਰਕਾਸ਼ਨ ਮੁੜ-ਪੜ੍ਹਤ ਨਾਲ ਮਿਲਦੇ ਹਨ, ਰਨਟਾਈਮ ਸੀਮਾਵਾਂ ਸਪਸ਼ਟ ਹਨ ਅਤੇ ਬਹਾਲੀ ਸਥਿਤੀ ਮਿਲਾਈ ਗਈ ਹੈ। Done ਲਈ ਪੰਜ Supported ਜਾਂਚਾਂ ਅਤੇ ਕੋਈ ਬਿਨਾਂ ਅਧਿਕਾਰ ਲਿਖਤ ਨਾ ਹੋਵੇ।

ਅਣਿਸ਼ਚਿਤ ਲਿਖਤ ਸੰਭਾਲੋ #

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

1. ਅਗਲਾ ਕਦਮ ਰੋਕੋ: ਡਿਲਿਵਰੀ ਅਧੂਰੀ ਰੱਖੋ।
2. ਮੰਜ਼ਿਲ ਪੜ੍ਹੋ: ਮੌਜੂਦਾ ਲਿਖਤ, ਵਰਜਨ ਅਤੇ ਦਾਇਰੇ ਦੀ ਨਿਸ਼ਚਿਤ ਪੈਕੇਜ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।
3. ਨਿਰੀਖਣ ਦਰਜ ਕਰੋ: ਪੂਰਾ, ਅਣਬਦਲਿਆ, ਟਕਰਾਅ ਵਾਲਾ ਜਾਂ ਅਪਹੁੰਚ।
4. ਅਗਲਾ ਕੰਮ ਚੁਣੋ: ਜਾਂਚੀ ਪੂਰਨ ਸਥਿਤੀ ਤੋਂ ਜਾਰੀ ਰੱਖੋ, ਮਨਜ਼ੂਰ ਅਣਬਦਲਿਆ ਕਦਮ ਮੁੜ ਅਜ਼ਮਾਓ ਜਾਂ ਟਕਰਾਅ ਅੱਗੇ ਭੇਜੋ।
5. ਅਣਿਸ਼ਚਿਤਤਾ ਕਾਇਮ ਰੱਖੋ: ਨਾਕਾਮ/ਅਣਜਾਣ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਬਾਅਦਲੀ ਮੁੜ-ਪੜ੍ਹਤ ਨਾਲ ਰੱਖੋ।

ਪੂਰਾ ਕ੍ਰਮ ਅੰਨ੍ਹੇਵਾਹ ਦੁਹਰਾਓ ਨਾ। ਪੂਰੇ ਹੋਏ ਕਦਮ ਨੂੰ ਫਿਰ ਕਰਨ ਨਾਲ ਰਿਵਿਜ਼ਨ ਵਧਦੇ ਹਨ ਅਤੇ ਗੈਰ-ਸੰਬੰਧਤ ਸੋਧ ਮਿਟਣ ਦਾ ਖ਼ਤਰਾ ਹੁੰਦਾ ਹੈ। ਜਾਂਚੀ ਸਥਿਤੀ ਤੋਂ ਮੁੜ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਸਰੋਤ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ, ਤਾਂ ਪੁਰਾਣੇ ਲੇਜਰ ਤੋਂ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ Hold ਚੁਣੋ।

ਬਹਾਲੀ ਦੇ ਫੈਸਲੇ ਤੁਲਨਾ ਕਰੋ #

ਮੌਜੂਦਾ ਸਥਿਤੀ ਅਤੇ ਮਾਲਕ ਦੇ ਫੈਸਲੇ ਮੁਤਾਬਕ ਚੋਣ ਕਰੋ। ਅੱਗੇ ਪੂਰਾ ਕਰਨ ਲਈ ਤਾਜ਼ੀ ਮਨਜ਼ੂਰੀ ਅਤੇ ਕਾਰਗਰ ਨਿਯੰਤਰਣ ਚਾਹੀਦੇ ਹਨ। ਮੁਆਵਜ਼ੇ ਲਈ ਵਿਚਕਾਰਲੀਆਂ ਸੋਧਾਂ ਦੇ ਹਿਸਾਬ ਨਾਲ ਬਹਾਲੀ ਦੀ ਸਮੀਖਿਆ ਕਰੋ। ਬਹਾਲੀ ਬਦਲਾਅ ਇੱਕ ਹੋਰ ਪ੍ਰਕਾਸ਼ਨ ਹੈ, ਪ੍ਰਕਿਰਿਆ ਦਾ ਖਾਸ ਛੋਟ ਨਹੀਂ।

ਪ੍ਰਕਾਸ਼ਨ ਪੂਰਨਤਾ ਜਾਂਚ #

ਅਜਿਹਾ ਪੈਕੇਜ ਦਿਓ ਜਿਸਨੂੰ ਸੁਤੰਤਰ ਸਮੀਖਿਅਕ ਮਿਲਾ ਸਕੇ। ਉਸਨੂੰ ਠੀਕ ਸਮੀਖਿਆ ਕੀਤਾ ਪ੍ਰਸਤਾਵ, ਸਰੋਤ-ਆਧਾਰ, ਦੋਵੇਂ ਭੂਮਿਕਾ-ਸਮੀਖਿਆਵਾਂ, ਹਰ ਲਿਖਤ ਦਾ ਨਤੀਜਾ, ਅੰਤਿਮ ਮੁੱਲ ਅਤੇ ਬਾਕੀ ਰਨਟਾਈਮ ਸੀਮਾਵਾਂ ਮਿਲਣ। ਰੁਕਾਵਟ ਤੋਂ ਬਾਅਦ ਪਹਿਲਾ ਅਧੂਰਾ ਕਦਮ ਪਛਾਣਣ ਲਈ ਕਹੋ।

ਉਮੀਦਿਤ ਤਰਕ: ਅਗਲਾ ਕੰਮ ਤਾਜ਼ੇ ਸਰੋਤਾਂ ਅਤੇ ਲੇਜਰ ਤੋਂ ਨਿਕਲਦਾ ਹੈ, ਪਿਛਲੇ ਸਹਾਇਕ ਦੇ ਭਰੋਸੇ ਤੋਂ ਨਹੀਂ। ਅੰਤਿਮ ਮੈਪ ਕੀਤੇ ਹਵਾਲੇ retrieval ਟੈਸਟਾਂ ਵਿੱਚ ਲਿਜਾਓ, ਜਿੱਥੇ ਖੋਜ ਨੂੰ ਉਹੀ ਅਧਿਕਾਰ-ਫਰਕ ਕਾਇਮ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ।

ਸਮੱਸਿਆ-ਨਿਵਾਰਣ ਅਤੇ ਬਹਾਲੀ #

ਵਰਜਨ ਬਦਲਿਆ: ਇਤਿਹਾਸ ਦੀ ਤੁਲਨਾ ਕਰਕੇ ਸਮੀਖਿਆ ਨਵੀਂ ਲਵੋ। ਸਨੈਪਸ਼ਾਟ ਜਾਂਚ ਪਾਸ ਪਰ wiki ਵੱਖਰੀ: ਮੌਜੂਦਾ Confluence ਸਰੋਤ ਮੁੜ ਲਵੋ। Done ਜਲਦੀ ਹੋ ਗਿਆ: ਮਨਜ਼ੂਰ ਪ੍ਰਕਿਰਿਆ ਰਾਹੀਂ ਮੁੜ ਖੋਲ੍ਹੋ ਅਤੇ ਗੁੰਮ ਕਦਮ ਲਿਖੋ।

ਬਹਾਲੀ: Page History ਤੁਲਨਾ ਅਤੇ ਮਾਲਕ ਵੱਲੋਂ ਸਮੀਖਿਆ ਕੀਤੀ ਬਹਾਲੀ ਜਾਂ ਮੁਆਵਜ਼ਾ-ਸੋਧ ਵਰਤੋ। ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਬਹਾਲੀ ਨੰਬਰ ਵਾਪਸ ਕਰਦੀ ਹੈ, ਨਤੀਜੇ ਦਾ ਵਰਜਨ ਦਰਜ ਕਰੋ। ਪ੍ਰੋਡਕਟ ਵਾਪਸੀ ਚੁਣੇ ਤਾਂ ਸੁਰੱਖਿਅਤ PR ਰਾਹੀਂ ਕਨਫਿਗਰੇਸ਼ਨ ਵਾਪਸ ਕਰੋ। ਮਿਟਾਈਆਂ ਫਾਈਲਾਂ ਵਾਪਸੀ ਦੀ ਗਾਰੰਟੀ ਤੋਂ ਬਾਹਰ ਹਨ।

ਅਭਿਆਸ ਅਤੇ ਸਵੈ-ਜਾਂਚ #

REQ-17 ਪ੍ਰਕਾਸ਼ਿਤ ਹੋਣ ਮਗਰੋਂ ਰੁਕੋ ਅਤੇ ਦੂਜੇ ਪ੍ਰਕਾਸ਼ਕ ਨੂੰ ਸਿਰਫ਼ ਮੈਪ ਅਤੇ ਲੇਜਰ ਦਿਓ।

ਉਮੀਦਿਤ ਤਰਕ: ਉਹ ਮੌਜੂਦਾ ਸਰੋਤ ਲਵੇਗਾ, ਨਿਸ਼ਚਿਤ ਮਨਜ਼ੂਰੀ ਪੱਕੀ ਕਰੇਗਾ ਅਤੇ ਸਿਰਫ਼ ਮਨਜ਼ੂਰ ਬਕਾਇਆ ਕਦਮ ਜਾਰੀ ਕਰੇਗਾ। ਸਬੂਤ ਦੀ ਘਾਟ ਕੰਮ ਨੂੰ Review ਵੱਲ ਵਾਪਸ ਭੇਜਦੀ ਹੈ।

ਮੁੱਖ ਹਵਾਲੇ #

• ਇਤਿਹਾਸ ਅਤੇ ਬਹਾਲੀ: Confluence ਤਕਨੀਕੀ ਦਸਤਾਵੇਜ਼ .
• ਵਰਜਨ ਵਾਲੇ API ਕੰਮ: Confluence REST API v2 ਪੇਜ .
• ਵਰਕਫਲੋ ਨਿਯੰਤਰਣ: Jira ਉੱਨਤ ਵਰਕਫਲੋ .
• ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਸੁਰੱਖਿਆ: MCP ਸੁਰੱਖਿਆ ਦੇ ਸਰਵੋਤਮ ਅਭਿਆਸ .

ਅਗਲੇ ਕਦਮ #

ਸਮੀਖਿਆਸ਼ੁਦਾ ਪ੍ਰਕਾਸ਼ਨ ਦੌਰ ਪੂਰਾ ਕਰਨ ਮਗਰੋਂ ਮੈਪ-ਪਹਿਲਾਂ ਰਿਟਰੀਵਲ ਜਾਰੀ ਰੱਖੋ।