AI सहयोग कैपस्टोन: GitHub, Confluence और Jira

AI सहयोग पाठ्यक्रम पर लौटें

PROP-042 को दो बार पूरा करें। पहला GitHub-first से और दूसरा GitHub के साथ Confluence/Jira से। आप योगदान देंगे, अलग मालिक समीक्षा करेंगे और अधिकृत प्रकाशक बदलाव लागू करेंगे। पिछली शिक्षाओं के बाद अलग सिंथेटिक सैंडबॉक्स का उपयोग करें। कैपस्टोन सहायक की भाषा की गुणवत्ता नहीं, बल्कि अस्वीकृति, रिकवरी और स्वतंत्र हैंडऑफ सहित पूरी प्रक्रिया की जांच करता है।

मुख्य बातें #

• एक साझा बदलाव दोनों अधिकार मॉडलों की तुलना करता है।
• नकारात्मक परीक्षण सफल डिलीवरी जितने ही महत्वपूर्ण हैं।
• प्रमाण पैकेज स्वतंत्र समीक्षा में सहायता करते हैं।
• लैब पूरा होना प्रोडक्शन रोलआउट की अनुमति नहीं है।

शुरू करने से पहले #

पूर्वापेक्षाएं: पिछले पाठ्यक्रम मॉड्यूल , स्वीकृत सैंडबॉक्स एक्सेस और अलग समीक्षक। योजना समय: कई सत्रों में आठ से बारह घंटे, स्वतंत्र समीक्षा के अतिरिक्त। वास्तविक समय खाता सेटअप और सुधार कार्य पर निर्भर है। कठिनाई: उन्नत।

आवश्यक आर्टिफैक्ट: चार्टर, मैप, नीति, एडेप्टर, बेसलाइन, मैनिफेस्ट, तय प्रस्ताव, मालिक समीक्षाएं, लेजर, रिकवरी रिकॉर्ड और हैंडऑफ। योजना पर निर्भर अनुमतियां न मिलने पर पूरा होना ब्लॉक होगा। उन्हें अनुमानित पास न मानें।

परीक्षण से पहले हर ट्रैक के लिए एक प्रमाण डायरेक्टरी बनाएं। समीक्षक को चैट सारांश के बिना अभिनेता, स्रोत रिविजन, आजमाया गया कार्य, देखा गया परिणाम और अंतिम स्थिति पहचाननी चाहिए।

दो बेसलाइन स्थापित करें #

1. अलग रन बनाएं। उनके नाम GitHub-first और Mixed रखें। रिविजन और समीक्षा अलग रखें।
2. सात-दिन की बेसलाइन बहाल करें। हर ट्रैक की स्वीकृत प्रक्रिया से काम करें और परिणाम रिविजन दर्ज करें।
3. अस्वीकृति नियंत्रण जांचें। योगदानकर्ता और बाहर रखे उपयोगकर्ता के खातों से परीक्षण करें।
4. वर्तमान संदर्भ दर्ज करें। एडेप्टर और नीति की सहमति पक्की करें।
5. दायरा घोषित करें। तीस दिन का सिंथेटिक एक्सपोर्ट रिटेंशन रखें और वास्तविक डेटा, बैकअप व कानूनी होल्ड बाहर रखें।

PROP-042 सहसंबंध लेबल है, दोबारा उपयोग होने वाली स्वीकृति नहीं। हर रन का अपना स्थिर रिविजन और स्रोत प्रमाण होना चाहिए। रिपोर्ट में रन ID रखें।

GitHub-first डिलीवर करें #

GitHub पाठों के साथ Issue और उम्मीदवार PR खोलें। आवश्यकता, कॉन्फिगरेशन, प्रस्ताव और रनबुक साथ बदलें। सुरक्षित बेस दर्ज करें, विश्वसनीय जांच चलाएं और अंतिम कमिट पर उत्पाद तथा संचालन समीक्षा लें।

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

सैंडबॉक्स से वास्तविक संदर्भ भरें। यह रूपरेखा अपेक्षित मैपिंग है, पूरा प्रमाण नहीं। अनुरक्षक समीक्षा के बाद ही मर्ज करता है और फिर स्वतंत्र रूप से main पढ़ता है। अंतिम रिकॉर्ड जोड़ने के बाद Issue बंद करें।

Mixed ट्रैक डिलीवर करें #

Confluence संस्करण पढ़ें और Jira प्रस्ताव स्थिर करें। दोनों मालिकों की समीक्षा लें। डिलीवरी लंबित रखते हुए आवश्यकता प्रकाशित करें, कॉन्फिगरेशन मर्ज करें, रनबुक प्रकाशित करें और Done से पहले सभी सिस्टम दोबारा पढ़ें।

हर प्रकाशन दर्ज करें। पेज संस्करण, कमिट या ट्रांजिशन प्रमाण रखें। रिपॉजिटरी की आवश्यकता प्रतियां स्नैपशॉट हैं। स्थानीय चेकर Confluence का वर्तमान अधिकार सिद्ध नहीं करता।

मालिकाना जरूरत के अनुसार वर्कफ़्लो चुनें। GitHub-first सिस्टमों के बीच समन्वय घटाता है। Mixed ट्रैक कार्यस्थल बनाए रखता है और प्रकाशन व एक्सेस जांच जोड़ता है।

असफलता मैट्रिक्स चलाएं #

सिस्टमों का संघर्ष Mixed का हिस्सा है। GitHub-first में स्वीकृत फ़ाइल से अलग Issue विवरण का परीक्षण करें। बाकी लागू केस दोनों ट्रैक में चलाएं। स्थानीय वैलिडेटर की असफलता लाइव अनुमति प्रमाण का स्थान नहीं लेती।

हर फ़ाइल परीक्षण से पहले बनाएं। अपेक्षित परिणाम, देखा गया परिणाम, अभिनेता की भूमिका, प्रारंभिक और अंतिम रिविजन, मूल प्रमाण संदर्भ और समीक्षक का निर्णय दर्ज करें। ब्राउज़र रूट प्रॉम्प्ट direct push अस्वीकृति का प्रमाण नहीं है। दोनों ट्रैक की डायरेक्टरी अलग रखें।

अपेक्षित और देखे गए परिणाम अलग रखें। हर केस में रन ID, भूमिका, प्रारंभिक रिविजन, आजमाया कार्य, अपेक्षा, निरीक्षण, परिणाम रिविजन और समीक्षा निर्णय लिखें। साझा रिपोर्ट से पासवर्ड और खाता पहचान हटाएं।

पूर्णता का आकलन करें #

पास के लिए हर लागू पंक्ति का देखा गया प्रमाण और स्वतंत्र स्वीकृति चाहिए। समीक्षक अनुमतियां, स्रोत ताजगी, भूमिका समीक्षा, आंशिक प्रकाशन, हैंडऑफ पुनर्निर्माण और सुसंगतता लॉग जांचते हैं।

अनधिकृत प्रकाशन, अस्वीकृत पाठ का मॉडल तक पहुंचना या बदले बेस का मौन ओवरराइट तुरंत असफलता है। सुधारित नियंत्रण दोबारा परीक्षण में पास होने तक काम ब्लॉक रखें। असफलताओं का औसत निकालकर अच्छा स्कोर न बनाएं।

पूर्ण और ब्लॉक केस, अस्वीकृत पुराने प्रस्ताव, रोके गए लेखन, रिकवरी और समीक्षा समय मापें। प्रस्तावित परिणाम देखे जाने तक अपेक्षित हैं। दिए गए दस यूनिट टेस्ट सुसंगतता कवर करते हैं, लाइव टेनेंट सुरक्षा नहीं।

दोनों रन की योजना बनाएं #

ट्रैक के बीच स्वीकृति दोबारा उपयोग न करें। मान समान है, पर स्रोत स्थान, कैप्चर रिविजन, अनुमतियां और प्रकाशन क्रम अलग हैं। हर रन को अपनी प्रमाण डायरेक्टरी और समीक्षा पैकेज दें।

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

ये नाम संगठन का उदाहरण हैं, दिए गए आर्काइव नहीं। वास्तविक प्रमाण स्वीकृत सैंडबॉक्स में निजी रखें। साझा सबमिशन में भूमिका लेबल और छिपे संदर्भ रखें। समीक्षक मूल रिकॉर्ड का एक्सेस बनाए रखें।

असफलताएं चलाने से पहले टेस्ट ऑब्जर्वर नियुक्त करें। योगदानकर्ता कार्य करेगा। ऑब्जर्वर प्रारंभिक स्थिति, परिणाम और अंतिम स्थिति लिखेगा। समीक्षक बाद में तय करेगा कि प्रमाण दावे को सहारा देता है या नहीं। स्वतंत्र स्वीकृति का संकेत देने के बजाय भूमिका ओवरलैप बताएं।

असफलताएं अलग-अलग चलाएं #

केस के बीच सत्यापित और समीक्षित स्थिति पर रीसेट करें। स्रोत विचलन, एक्सेस रद्दीकरण और रनबुक अंतर एक साथ डालने से अस्वीकृति का कारण छिप जाता है। एक रन में एक असफलता से कारण ट्रेस किया जा सकता है।

1. प्रारंभिक स्थिति कैप्चर करें: स्रोत रिविजन, कॉन्फिगरेशन, डिलीवरी स्थिति और अभिनेता की भूमिका।
2. एक सिंथेटिक इंजेक्शन लगाएं: अधिकृत परीक्षण मार्ग से एक संबंधित शर्त बदलें।
3. सीमित कार्य आजमाएं: वैलिडेशन, पढ़ना, प्रकाशन या हैंडऑफ।
4. निरीक्षण दर्ज करें: वास्तविक आउटपुट और स्रोत की अंतिम स्थिति।
5. समीक्षा से सुधारें: नियंत्रण बहाल करने से पहले असफलता प्रमाण बचाएं।
6. सकारात्मक केस दोहराएं: पुष्टि करें कि सुधरा वर्कफ़्लो अनुमत काम देता है।

नियोजित असफलता भी असफलता का निरीक्षण है। अनधिकृत प्रकाशन को सफल परीक्षण न कहें क्योंकि आप नियंत्रण जांचना चाहते थे। परीक्षण ने दोष दिखाया, लेकिन प्रकाशन सीमा विफल हुई और सुधार चाहिए।

मिश्रित परिणाम समझें #

उदाहरण प्रमाण पैकेज: स्थानीय सुसंगतता पास है, उत्पाद और संचालन तय पैकेज की समीक्षा करते हैं, आवश्यकता का प्रकाशन सफल है और रनबुक बदलाव एक्सेस अस्वीकार है। कॉन्फिगरेशन अभी मर्ज नहीं हुई। Jira Blocked है।

अपेक्षित सोच: रन अधूरा रखें, वर्तमान स्रोत जांचें और उचित मालिक का निर्णय मांगें। अनुमति कमजोर करके या स्नैपशॉट जांच को लाइव प्रकाशन प्रमाण बताकर पूरा न करें।

स्वतंत्र पाठक से समीक्षा कराएं #

समीक्षक से घटनाओं का पुनर्निर्माण करने को कहें, केवल निष्कर्ष पढ़ने को नहीं। उसे आपकी कहानी के बिना स्वीकृत बेसलाइन, तय प्रस्ताव, मालिक के निर्णय, परिणाम रिविजन, विफल प्रयास, सुधार और शेष अंतर खोजने चाहिए।

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?

हर आवश्यकता को अलग स्कोर दें। प्रमाण संदर्भ के साथ Supported, Failed, Blocked या Not run लिखें। सुसंगतता, स्वीकृति, अनुमतियां, रिकवरी और हैंडऑफ अलग आवश्यकताएं हैं। स्थानीय हरे परीक्षण लाइव प्रकाशन सीमा की विफलता को नहीं छिपाते।

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 का अर्थ है कि समीक्षक ने हर लागू केस के लिए देखा गया प्रमाण पाया। देखी गई नियंत्रण विफलता के लिए Failed, गायब एक्सेस या नियंत्रण के लिए Blocked और न किए गए केस के लिए Not run लिखें। हर मूल संदर्भ नामित प्रमाण फ़ाइल में रखें।

पाठ्यक्रम पास गेट: GitHub-first और Mixed दोनों ट्रैक पूरे करें। हर ट्रैक में ऊपर के सभी आठ लागू केस Supported होने चाहिए। Failed सीमा या मूल read-back की कमी ट्रैक ब्लॉक करती है। भुगतान योजना या टेस्ट पहचान न मिलने पर Blocked लिखें, अनुमानित पास नहीं। एक पूरा ट्रैक आंशिक दस्तावेजित परिणाम देता है, पाठ्यक्रम पूर्णता नहीं।

संपादित मॉडल पैकेज, केवल उदाहरण:

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

हर उदाहरण संदर्भ को सैंडबॉक्स में देखे गए आर्टिफैक्ट से बदलें। Mixed के लिए उसके अपने स्रोत संस्करण और समीक्षाओं के साथ पूरा पैकेज दोहराएं। समीक्षक Mixed पैकेज में कॉपी की गई GitHub स्वीकृति अस्वीकार करे।

सीमित निर्णय लिखें #

उपयोगी अंतिम निर्णय अगले पायलट का नाम देता है, असीमित रोलआउट का नहीं। उदाहरण के लिए समान भूमिकाओं और सीधे lookup मार्ग के साथ दूसरी सिंथेटिक एक्सपोर्ट सेटिंग चुनें, और वास्तविक डेटा तथा स्वचालित प्रकाशन बाहर रखें।

पूर्णता जांच: दोनों रन पैकेज स्वतंत्र पुनर्निर्माण में टिकते हैं, लागू असफलता केस के प्रमाण देखे गए हैं और अनसुलझे नियंत्रण दिखाई देते हैं। केवल GitHub ट्रैक पूरा हो तो Mixed के समान व्यवहार का अनुमान न लगाएं। आंशिक पाठ्यक्रम पूर्णता दर्ज करें।

समस्या निवारण और बैकआउट #

केवल सफल रास्ते का प्रमाण: अस्वीकृति और रुकावट परीक्षण दोहराएं। भूमिका ओवरलैप: उसे बताएं और अलग उपयोगकर्ताओं के साथ दोहराएं। योजना नियंत्रण गायब: रुकें और स्वीकृत सैंडबॉक्स लें।

बैकआउट: समीक्षित PR और Confluence बदलाव से बेसलाइन बहाल करें, अस्थायी इंटीग्रेशन रद्द करें, Jira प्रमाण संग्रहित करें और प्रमाण बचाने के बाद मालिक-स्वीकृत सिंथेटिक सफाई करें। रिकवरी इतिहास रखें।

रोलआउट निर्णय बनाएं #

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

अपेक्षित सोच: सिंथेटिक सफलता एक और सीमित पायलट का आधार है। प्रोडक्शन के लिए वास्तविक डेटा, डिप्लॉयमेंट, प्रदाता प्रबंधन और रनटाइम व्यवहार पर अलग स्वीकृति चाहिए। सहायक का सफल उत्तर डिप्लॉयमेंट अनुमति नहीं है।

मुख्य संदर्भ #

• रिपॉजिटरी नियंत्रण: सुरक्षित ब्रांच ।
• कार्यस्थल एक्सेस: Confluence अनुमतियां ।
• डिलीवरी नियंत्रण: Jira अनुमति स्कीम ।

अगले कदम #

पाठ्यक्रम हब पर लौटें और गायब नियंत्रणों की समीक्षा करें। दूसरा पायलट चुनने से पहले अपने कार्यान्वयन की तुलना फ्रेमवर्क लेख से करें।