OpenTag कसे सेट करावे: Slack आणि GitHub साठी मार्गदर्शक

जेव्हा तुम्ही एखाद्या एजंटचा उल्लेख करता तेव्हा OpenTag काय करते

जेव्हा तुम्ही Slack थ्रेड किंवा GitHub इश्यूमध्ये @mention करता, तेव्हा OpenTag त्याचे रूपांतर तुमच्या मालकीच्या मशीनवर चालणाऱ्या कोडिंग एजंटमध्ये करते. कोणीतरी एखाद्या इश्यूवर @opentag investigate this अशी कमेंट करते. एक लिसनर (listener) प्लॅटफॉर्म इव्हेंट प्राप्त करतो, त्याची स्वाक्षरी तपासतो, त्या उल्लेखाला संबंधित प्रोजेक्टशी जोडतो, स्थानिक चेकआउटवर कोडिंग एजंट सुरू करतो आणि निकाल पुन्हा त्याच थ्रेडमध्ये पोस्ट करतो.

हा प्रोजेक्ट MIT लायसन्स अंतर्गत आहे आणि amplifthq/opentag येथे उपलब्ध आहे. ऑगस्ट 2026 पर्यंत, सर्वात नवीन टॅग केलेली आवृत्ती v0.9.0 आहे, जी 28 जुलै 2026 रोजी प्रकाशित झाली असून ती npm पॅकेज म्हणून उपलब्ध आहे. याची कोणतीही अधिकृत कंटेनर इमेज नाही, त्यामुळे तुम्ही npm आवृत्तीच पिन करता. खालील प्रत्येक कमांड ती पिन करते.

GitHub च्या स्वरूपामुळे हा लॅपटॉपऐवजी VPS प्रोजेक्ट बनतो. GitHub रिपॉझिटरी इव्हेंट्स पाठवण्यासाठी तुम्ही एकदा नोंदणी केलेल्या URL वर HTTP विनंती करते, त्यामुळे ती URL उद्याही त्याच पत्त्यावर उपलब्ध असणे आवश्यक आहे.

चार मुख्य घटक

Listener प्लॅटफॉर्म इव्हेंट्स स्वीकारतो आणि प्रत्येक प्लॅटफॉर्मसाठी तो वेगळा असतो. GitHub listener हा पोर्ट 3050 वर /github/webhooks या पाथवर असलेला एक HTTP endpoint आहे. Slack Events API listener हा पोर्ट 3040 वर /slack/events येथे असतो. Slack 'Socket Mode' मध्ये देखील चालू शकते, जिथे ॲप एक आउटबाउंड WebSocket उघडते आणि त्याला कोणत्याही इनबाउंड पोर्टची गरज नसते.

Dispatcher हा समन्वयक आहे. तो डीफॉल्टनुसार पोर्ट 3030 वर ऐकतो, OPENTAG_DATABASE_PATH द्वारे सेट केलेल्या स्थानिक डेटाबेस फाईलमध्ये रन स्टेट ठेवतो आणि प्रत्येक रनसाठी ऑडिट ट्रेल नोंदवतो. बॉक्सच्या बाहेरील कोणत्याही गोष्टीने या पोर्टवर पोहोचू नये.

Runner हा स्थानिक डेमन (daemon) आहे. तो कामासाठी पोलिंग करतो, रन क्लेम करतो, त्यावर लीज (lease) ठेवतो आणि रन सुरू असताना डीफॉल्टनुसार दर 15 सेकंदांनी हार्टबीट पाठवतो. जर प्रोजेक्ट टार्गेट गहाळ असेल किंवा त्याच्या स्वतःच्या कॉन्फिगरेशनमधील अलाउलिस्टच्या बाहेर असेल, तर तो कोणताही क्लेम केलेला रन नाकारतो. ही ती तपासणी आहे जी GitHub इव्हेंटला तुमच्या एजंटला अशा रिपॉझिटरीकडे निर्देशित करण्यापासून रोखते जी तुम्ही कधीही बाइंड केलेली नाही.

Executor हा स्वतः कोडिंग एजंट आहे. OpenTag त्याला ACP (agent client protocol) द्वारे लाँच करते. हे एक JSON-RPC प्रोटोकॉल आहे जे स्टँडर्ड इनपुट आणि आउटपुटवर चालते, त्यामुळे एजंट OpenTag ने दिलेल्या वर्किंग डिरेक्टरीमध्ये चाइल्ड प्रोसेस म्हणून चालतो. अंगभूत नावांमध्ये echo, codex, claude-code, cursor, opencode, hermes आणि openclaw यांचा समावेश आहे. echo ने सुरुवात करा, जो उदाहरणादाखल दिलेल्या कॉन्फिगरेशनसोबत येतो. हे सिद्ध करते की मॉडेल तुमच्या कोडला स्पर्श करण्यापूर्वी संपूर्ण पाथ योग्यरित्या काम करत आहे.

क्रम कधीही बदलत नाही: प्लॅटफॉर्म इव्हेंट, सिग्नेचर चेक, रन रेकॉर्ड, क्लेम, एजंट, थ्रेडमधील उत्तर.

लॅपटॉप आणि टनेल पुरेसे का नसतात

GitHub सेटअप मार्गदर्शिकेनुसार तुम्हाला ngrok http 3050 चालवून टनेल होस्ट रिपॉझिटरी वेबहूक (webhook) मध्ये पेस्ट करण्यास सांगितले जाते. हे पहिल्या दहा मिनिटांसाठी काम करते. मोफत टनेल होस्ट प्रत्येक वेळी प्रक्रिया रीस्टार्ट झाल्यावर बदलतो आणि लॅपटॉप स्लीप मोडमध्ये गेल्यावर तो अस्तित्वात राहत नाही. GitHub जुना payload URL वापरत राहते आणि प्रयत्न करत राहते, त्यामुळे वेबहूक सेटिंग्जमधील Recent Deliveries टॅबमध्ये अपयशांची नोंद भरत जाते, तर दुसरीकडे थ्रेड शांत राहतो. कोणाचेही याकडे एक आठवडा लक्ष जात नाही, कारण काहीही न करणारा वेबहूक हा कोणाचेही लक्ष नसलेल्या बॉटसारखाच दिसतो.

VPS मुळे या दोन समस्या सुटतात. DNS नाव बदलत नाही, त्यामुळे तुम्ही एकदा पेस्ट केलेला payload URL कायमस्वरूपी योग्य राहतो. मशीन स्लीप मोडमध्ये जात नाही, त्यामुळे रात्री 02:00 वाजता आलेल्या कमेंटलाही उत्तर मिळते. प्रथम सर्व्हर योग्यरित्या सेट करा: नवीन VPS वरील पहिली दहा मिनिटे या मार्गदर्शिकेमध्ये लॉगिन युजर आणि फायरवॉलची माहिती दिली आहे, जी या मार्गदर्शिकेसाठी गृहीत धरली आहे.

Slack हा एक अपवाद आहे. Socket Mode मध्ये ते बाहेरून कनेक्ट होते आणि त्याला सार्वजनिक URL ची गरज नसते, त्यामुळे फक्त Slack साठीचे डिप्लॉयमेंट सुरक्षित राहू शकते. GitHub कडे असा कोणताही पर्याय नाही. रिपॉझिटरी वेबहूक हे inbound HTTP असतात, ज्याचा अर्थ असा की त्यासाठी सार्वजनिक एंडपॉइंट, TLS (transport layer security) आणि सिग्नेचर तपासणीची आवश्यकता असते.

Ubuntu वर pinned release वापरून OpenTag self-host करणे

OpenTag v0.9.0 साठी Node.js 22 किंवा त्यापेक्षा नवीन आवृत्ती आवश्यक आहे. Ubuntu 24.04 च्या स्वतःच्या रिपॉझिटरीमध्ये Node 18 उपलब्ध आहे, म्हणून NodeSource वरून इन्स्टॉल करा.

curl -fsSL https://deb.nodesource.com/setup_22.x -o nodesource_setup.sh
sudo -E bash nodesource_setup.sh
sudo apt install -y nodejs
node -v

node -v ने v22 किंवा त्यापेक्षा जास्त आवृत्ती दर्शविली पाहिजे. Node 20 वर इन्स्टॉल करताना EBADENGINE चे वॉर्निंग येते आणि CLI सुरू झाल्यावर अयशस्वी होऊ शकते.

या सेवेसाठी स्वतंत्र खाते तयार करा. एजंट या वापरकर्त्याच्या परवानग्यांसह चालतो, त्यामुळे ते तुमचे लॉगिन खाते किंवा root नसावे. VPS वरील Least privilege users मध्ये हे विलगीकरण का महत्त्वाचे आहे, हे स्पष्ट केले आहे.

sudo adduser --disabled-password --gecos "" opentag
sudo loginctl enable-linger opentag
sudo npm install -g @opentag/cli@0.9.0
command -v opentag

command -v opentag ने /usr/bin/opentag सारखा पाथ दर्शविला पाहिजे. Linux वर linger सेटिंग महत्त्वाची आहे: OpenTag आपली बॅकग्राउंड सेवा systemd द्वारे इन्स्टॉल करते आणि linger नसलेली युजर सेवा तुमचे SSH सत्र बंद होताच थांबते.

त्या वापरकर्त्याच्या नावाने सेटअप चालवा.

sudo -iu opentag opentag setup

सेटअप सहा गोष्टी विचारतो: CLI भाषा, स्थानिक listening पत्ता, कोडिंग एजंट, काम करण्यासाठी स्थानिक प्रोजेक्ट, सेव्ह करण्यासाठी प्लॅटफॉर्म क्रेडेंशियल्स आणि रन करण्याची पद्धत. listening पत्ता 127.0.0.1 वरच ठेवा, कारण nginx TLS termination हाताळते आणि विनंत्या फॉरवर्ड करते, त्यामुळे हे listeners बाहेरून उपलब्ध असण्याची गरज नाही. GitHub साठी ते owner/repo फॉरमॅटमध्ये रिपॉझिटरी, pull requests उघडण्याची परवानगी, webhook पोर्ट (डीफॉल्टनुसार 3050) आणि टोकन विचारते. शेवटी बॅकग्राउंड सर्व्हिस मोड निवडा. जर तुमच्याकडे आधीच कॉन्फिगरेशन असेल आणि तुम्हाला प्रॉम्प्टशिवाय सेवा इन्स्टॉल करायची असेल, तर opentag setup --service वापरा.

कॉन्फिगरेशन /home/opentag/.config/opentag/config.json मध्ये आणि रनटाइम स्टेट /home/opentag/.local/state/opentag मध्ये सेव्ह होते. सेटअप फाइल लिहिल्यानंतर या कीज स्वतः तपासून पाहणे फायदेशीर ठरते.

{
  "runnerId": "runner_local",
  "dispatcherUrl": "http://localhost:3030",
  "runnerToken": "...",
  "approvalMode": "ask",
  "repositories": []
}

जुने शेअर केलेले pairingToken वापरण्याऐवजी, रनर-स्कोप केलेले bearer token म्हणजेच runnerToken वापरणे अधिक श्रेयस्कर आहे. कॉन्फिगरेशन फाइलमध्ये क्रेडेंशियल्स प्लेन टेक्स्टमध्ये असतात, जोपर्यंत तुम्ही त्यांना secret reference ने बदलत नाही. हे reference स्टार्टअपच्या वेळी environment किंवा डिस्कवरील फाइलमधून व्हॅल्यू वाचते. कोणतीही पद्धत वापरली तरी, ही फाइल सर्व्हरवरील सर्वात संवेदनशील गोष्ट आहे: मोड 600 ठेवा, मालकी opentag कडे ठेवा आणि ती कधीही git रिपॉझिटरीमध्ये ठेवू नका. याबद्दलचा सविस्तर युक्तिवाद AI एजंट्सपासून secrets सुरक्षित ठेवणे मध्ये दिला आहे.

कोणतीही गोष्ट उघड करण्यापूर्वी इन्स्टॉलेशन तपासा.

sudo -iu opentag opentag doctor
sudo -iu opentag opentag status

opentag doctor डिस्पॅचर, बाइंडिंग्स, चेकआउट्स आणि एक्झिक्युटर्स तपासते. opentag status कॉन्फिगरेशन आणि रनटाइम स्टेट प्रिंट करते, आणि एकदा रन सुरू झाल्यावर ते एका विशिष्ट रनपुरते मर्यादित करता येते. तुम्ही या सर्व्हरला प्लॅटफॉर्मशी जोडण्यापूर्वी doctor द्वारे रिपोर्ट केलेल्या सर्व त्रुटी दुरुस्त करा.

TLS ला समोर ठेवा आणि फक्त दोन पाथ उघडा

Nginx TLS टर्मिनेट करते आणि नेमके दोन पाथ फॉरवर्ड करते. इतर सर्व विनंत्यांसाठी 404 एरर येतो, त्यामुळे होस्ट शोधणाऱ्या स्कॅनरला मागे काय चालले आहे याची माहिती मिळत नाही.

/etc/nginx/sites-available/opentag वर एक साधे port 80 सर्व्हर ब्लॉक लिहा आणि खालील दोन लोकेशन्स समाविष्ट करा, त्यानंतर Certbot ला TLS चा भाग जोडण्यास सांगा.

sudo apt install -y nginx certbot python3-certbot-nginx
sudo ln -s /etc/nginx/sites-available/opentag /etc/nginx/sites-enabled/opentag
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d opentag.example.com

nginx -t हे syntax is ok आणि test is successful प्रिंट करते, आणि टाईपोमुळे साईट बंद पडण्यापासून वाचवणारा हा एकमेव मार्ग आहे. Ubuntu 24.04 वर nginx सह Certbot मध्ये रिन्यूअल आणि ACME (automatic certificate management environment) चॅलेंज का अपयशी ठरते याबद्दल माहिती दिली आहे. पूर्ण झालेले ब्लॉक खालीलप्रमाणे दिसते.

server {
    listen 443 ssl;
    server_name opentag.example.com;

    ssl_certificate     /etc/letsencrypt/live/opentag.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/opentag.example.com/privkey.pem;

    client_max_body_size 2m;

    location = /github/webhooks {
        proxy_pass http://127.0.0.1:3050;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }

    location = /slack/events {
        proxy_pass http://127.0.0.1:3040;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }

    location / {
        return 404;
    }
}

location = /github/webhooks मधील = हे अचूक मॅच (exact match) आहे, आणि पोर्टनंतर काहीही न देता proxy_pass वापरल्यास मूळ URI जसाच्या तसा पुढे पाठवला जातो. = काढून टाका, अन्यथा /github/webhooks/ अंतर्गत येणारे सर्व पाथ फॉरवर्ड होतील, जे आवश्यकतेपेक्षा जास्त एक्सपोजर आहे.

फायरवॉल मर्यादित ठेवा.

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status

पोर्ट 3030, 3040 आणि 3050 कधीही उघडू नका. ते सर्व इंटरफेसऐवजी फक्त loopback वर बाइंड झाले आहेत याची खात्री करा.

sudo ss -tlnp

प्रत्येक OpenTag ओळ 127.0.0.1:3030 किंवा तत्सम असावी. जर ओळ 0.0.0.0:3050 अशी असेल, तर याचा अर्थ असा की लिसनर संपूर्ण इंटरनेटसाठी खुला आहे आणि फक्त ufw मुळे तो थांबला आहे; फायरवॉलमध्ये एक छोटी चूक झाल्यास तो उघडा पडू शकतो. ufw फायरवॉलची मूलभूत माहिती मध्ये डीफॉल्ट 'deny' धोरण नक्की काय करते हे स्पष्ट केले आहे.

दोन तपासण्या मुख्य दरवाजा सुरक्षित असल्याची खात्री देतात. curl -I https://opentag.example.com/ हे nginx कडून 404 रिटर्न करते, जे दर्शवते की प्रमाणपत्र वैध आहे आणि कॅच-ऑल (catch-all) बंद आहे. कोणतीही स्वाक्षरी नसलेली /slack/events किंवा /github/webhooks कडील विनंती कधीही 200 रिस्पॉन्स देऊ नये.

प्रत्येक स्वाक्षरीची पडताळणी करा, कारण URL सार्वजनिक आहे

कोणीही ही पेलोड URL शोधू शकते. ती तुमच्या रिपॉझिटरी सेटिंग्जमध्ये, ब्राउझर हिस्ट्रीमध्ये किंवा तिकीटमध्ये पेस्ट केलेल्या स्क्रीनशॉटमध्ये असू शकते. केवळ स्वाक्षरीमुळेच खरी GitHub डिलिव्हरी आणि एखाद्याने हाताने टाईप केलेली विनंती यात फरक ओळखता येतो.

GitHub प्रत्येक डिलिव्हरीवर वेबहूक सीक्रेटने स्वाक्षरी करते आणि त्याचा निकाल x-hub-signature-256 हेडरमध्ये पाठवते. OpenTag त्या हेडरची पडताळणी platforms.github.webhookSecret च्या तुलनेत करते. प्रकल्पाच्या हार्डनिंग नोट्समध्ये हा नियम स्पष्टपणे नमूद केला आहे: /github/webhooks वर स्वाक्षरी नसलेल्या सोर्स इव्हेंट्स स्वीकारू नका. Slack प्रत्येक विनंतीवर SLACK_SIGNING_SECRET ने स्वाक्षरी करते आणि त्यात टाइमस्टॅम्प समाविष्ट करते, जेणेकरून कॅप्चर केलेला डेटा काही तासांनंतर पुन्हा वापरता (replay) येणार नाही.

हे दुर्लक्षित करणे मोठा धोका ठरू शकतो. पडताळणी न केलेले एंडपॉईंट हाताने लिहिलेला issue_comment पेलोड स्वीकारू शकते, ज्यामध्ये @opentag समाविष्ट असेल. त्यानंतर OpenTag तुमच्या टोकनचा वापर करून, तुमच्या चेकआउटमध्ये, अनोळखी व्यक्तीच्या सूचनांनुसार कोडिंग एजंट चालवेल. त्याचे उत्तर बनावट पेलोडमध्ये नमूद केलेल्या कोणत्याही थ्रेडवर पाठवले जाईल.

OpenTag यावर दोन स्तर जोडते. सोर्स डिलिव्हरीचा मागोवा डिलिव्हरी ID द्वारे घेतला जातो, त्यामुळे एकाच इव्हेंटची पुन्हा डिलिव्हरी केल्यास दुसरी रन सुरू होत नाही. रनर कॉल्स आयडेम्पोटन्सी की (idempotency keys) स्वीकारतात, त्यामुळे एखादी विनंती पुन्हा प्ले केल्यास, दुसरा ऑडिट इव्हेंट न जोडता केवळ यश (success) परत मिळते.

रेट लिमिट्स कॉन्फिगर करण्यायोग्य आहेत आणि ती सुरूच ठेवली पाहिजेत. OPENTAG_RATE_LIMIT_WINDOW_MS आणि OPENTAG_RATE_LIMIT_MAX_REQUESTS विनंतीचा दर मर्यादित करतात, OPENTAG_MAX_REQUEST_BODY_BYTES बॉडीची मर्यादा ठरवते आणि खूप मोठा पेलोड 413 request_body_too_large सह नाकारला जातो. OPENTAG_RATE_LIMIT_DISABLED=true केवळ स्थानिक डेव्हलपमेंटसाठी अस्तित्वात आहे आणि सार्वजनिक सर्व्हरवर त्याचा वापर करू नये. त्याच नोट्समधील आणखी एक नियम: सार्वजनिक रिले URL ने HTTPS वापरणे अनिवार्य आहे आणि CLI केवळ localhost साठी साध्या HTTP ला परवानगी देते.

बॉटला नेमके कोणते टोकन स्कोप आवश्यक आहेत?

GitHub वर, OpenTag हे GitHub App ऐवजी fine-grained personal access token वापरते. दस्तऐवजानुसार, App चा मार्ग नियोजित आहे आणि सध्या तो डीफॉल्ट CLI सेटअप नाही. याचा एक परिणाम असा होतो की, जो वापरकर्ता टोकन तयार करतो, त्याच्या नावाने बॉट कमेंट करतो. त्यामुळे, अशा खात्याचा वापर करून टोकन तयार करा ज्याचे नाव प्रत्येक triage रिप्लायमध्ये दिसणे तुम्हाला मान्य असेल.

सेटअप गाईडमध्ये सांगितल्याप्रमाणे स्कोप मर्यादित ठेवा. Only select repositories निवडा आणि एक रिपॉझिटरी निवडा. Issues: Read and write आणि Pull requests: Read and write हे परवानग्या द्या. थ्रेडमधील उल्लेख वाचण्यासाठी आणि उत्तर देण्यासाठी हे पुरेसे आहे.

काय आवश्यक नाही ते लक्षात घ्या: कोडसाठी write access. जोपर्यंत preparePullRequestBranch हे true वर सेट केलेले नसते, तोपर्यंत OpenTag ब्रांचेस पुश करत नाही. तसेच, एक स्वतंत्र githubApplyToken अस्तित्वात आहे, जेणेकरून कोड लिहिणारे टोकन आणि कमेंट्स लिहिणारे टोकन वेगवेगळे राहतील. त्यांना वेगळे ठेवा आणि जोपर्यंत read-and-comment मार्ग काही आठवडे व्यवस्थित चालत नाही, तोपर्यंत write टोकन बंद ठेवा.

All repositories साठी Contents: Read and write असलेले टोकन वापरणे टाळा. अशा परिस्थितीत, त्या रिपॉझिटरीजवर कमेंट करू शकणारी कोणतीही व्यक्ती कमिट अधिकार असलेल्या एजंटला नियंत्रित करू शकते आणि ऑडिट ट्रेलमध्ये टोकन मालकानेच हे केल्याचे दिसते. एजंटने विश्वास संपादन केल्यानंतर, एका वेळी एका रिपॉझिटरीसाठी स्कोप वाढवा.

Slack वर बॉटचे स्कोप app_mentions:read, chat:write, reactions:write आणि channels:history हे आहेत. खाजगी चॅनेलसाठी groups:history आणि message.groups इव्हेंटचे सबस्क्रिप्शन आवश्यक आहे. Socket Mode साठी connections:write असलेले app-level टोकन आवश्यक आहे, जे xapp- ने सुरू होते. channels:history हे बॉट ज्या सार्वजनिक चॅनेलमध्ये जोडला आहे, तिथला मेसेज इतिहास वाचते. त्यामुळे, सर्वत्र बॉट जोडण्याऐवजी जिथे गरज आहे तिथेच तो जोडा.

एका इश्यूसाठी एंड-टू-एंड राउटिंग

सर्वात आधी वेबहूक (webhook) सेट करा. रिपॉझिटरीमध्ये Settings उघडा, त्यानंतर Webhooks आणि मग Add webhook वर क्लिक करा. Payload URL https://opentag.example.com/github/webhooks आहे, content type application/json आहे आणि secret हे सेटअप दरम्यान तयार केलेले आहे. फक्त Issue comments आणि Pull request review comments साठी सबस्क्राईब करा, इतर कशालाही नको.

तुम्ही सेव्ह करताच GitHub एक पिंग डिलिव्हरी पाठवते. Recent Deliveries उघडा आणि विनंती सर्व्हरपर्यंत पोहोचली आहे का ते तपासा. तिथे 502 एरर येत असेल, तर याचा अर्थ nginx ला लिसनरपर्यंत पोहोचता येत नाहीये; ही एक स्थानिक समस्या आहे, GitHub ची नाही.

आता याचा वापर करा. एक बग दर्शवणारा इश्यू उघडा आणि खालीलप्रमाणे कमेंट करा:

@opentag triage this. Reproduce the report against the current main branch, then reply with the file and function most likely responsible, plus the test you would write first.

काय घडायला हवे, त्याचा क्रम असा आहे: Recent Deliveries मध्ये issue_comment डिलिव्हरी 2xx रिस्पॉन्ससह नोंदवली जाते. डिस्पॅचर एक रन रेकॉर्ड करतो. रनर ती रन क्लेम करतो आणि हार्टबीट सुरू करतो. एक्झिक्युटर चेकआउट उघडतो आणि काम सुरू करतो. उत्तर त्याच इश्यू थ्रेडमध्ये कमेंट म्हणून येते. sudo -iu opentag opentag status रन सुरू असताना ती दाखवते, त्यामुळे अंदाज लावण्याऐवजी तुम्ही ती थेट पाहू शकता.

पहिल्या प्रत्यक्ष रनच्या आधी approvalMode ला ask वर सेट करा. ask मोडमध्ये, रन थांबते आणि कोणतीही स्थिती बदलण्यापूर्वी मानवी हस्तक्षेपाची वाट पाहते. auto आणि autonomous मोड देखील उपलब्ध आहेत, आणि तुम्ही महिनाभर ट्रान्स्क्रिप्ट्स वाचल्यानंतर रिपॉझिटरीवर त्यांचा वापर करणे योग्य ठरेल.

Slack च्या बाजूने, तीच रन चॅनेलमध्ये /bind owner/repo ने सुरू होते, त्यानंतर एक मेंशन येते. बॉट /help, /status, /doctor, /stop आणि /unbind confirm ला देखील उत्तरे देतो. बाइंडिंग बदलण्याचा अधिकार कोणाला असावा हे OPENTAG_SLACK_BINDING_ADMIN_USER_IDS द्वारे मर्यादित करा (हे Slack युजर आयडींची स्वल्पविरामाने वेगळी केलेली यादी आहे), कारण बाइंडिंग म्हणजे सार्वजनिक चॅनेल आणि तुमच्या सर्व्हरवरील चेकआउट यांच्यातील मॅपिंग असते.

ट्रायज (Triage) हा एक चांगला पहिला मार्ग आहे कारण तो फक्त वाचतो, लिहित नाही आणि त्याचे उत्तर तपासणे सोपे असते. रिव्ह्यू (Review) ही पुढची पायरी आहे, जिथे एजंट इश्यूऐवजी डिफ (diff) वर कमेंट करतो: सेल्फ-होस्टेड पुल रिक्वेस्ट रिव्ह्यू एजंट हे याच आर्किटेक्चरचे पुल रिक्वेस्टसाठी केलेले स्वरूप आहे. जर तुम्हाला एजंटने काम करताना तुमच्या स्वतःच्या सिस्टिम्सपर्यंत पोहोचावे असे वाटत असेल, तर ते MCP servers on a VPS चे काम आहे. वेब सर्च ही दुसरी क्षमता आहे जी ट्रायज सतत मागत असते, आणि एजंटला तुमच्या स्वतःच्या SearXNG इन्स्टन्सशी जोडणे हे त्या शोधकार्यांना तुमच्या हार्डवेअरवर ठेवते, मात्र यामुळे अनोळखी मजकूर एजंटपर्यंत पोहोचण्यासाठी आणखी एक चॅनेल तयार होते.

जेव्हा एजंट सर्वांसमोर चुकीची माहिती देतो तेव्हा काय होते?

तो चुकीचा ठरेल. प्रश्न असा आहे की त्याची किंमत काय आहे.

सार्वजनिक समस्येवर (public issue) दिलेले चुकीचे उत्तर तुमच्या टीमला माहित असलेल्या नावाखाली केलेली टिप्पणी असते आणि ती पोस्ट होताच GitHub ती सबस्क्राईब केलेल्या प्रत्येकाला ईमेलद्वारे पाठवते. टिप्पणी हटवल्याने ईमेल परत येत नाही. Slack नोटिफिकेशनच्या बाबतीतही हेच घडते. उत्तराची खाजगीत बरोबर असण्यापेक्षा ते सार्वजनिक ठिकाणी चुकीचे असू शकते, हे लक्षात घेऊन नियोजन करा.

नुकसान मर्यादित ठेवण्यासाठी चार पर्याय आहेत आणि ते तुम्ही लिहिलेल्या कोणत्याही प्रॉम्प्टपेक्षा अधिक महत्त्वाचे आहेत.

• ask मोडमध्ये रन करा, जेणेकरून एजंट प्रस्ताव मांडेल, एखादी व्यक्ती त्याला मंजुरी देईल आणि चुकीच्या प्लॅनची किंमत फक्त एका क्लिकची असेल.
• preparePullRequestBranch ला त्याच्या डीफॉल्ट 'false' स्थितीवर ठेवा, जेणेकरून चुकीच्या रनचा सर्वात वाईट परिणाम चुकीच्या ब्रांचऐवजी फक्त चुकीची टिप्पणी असेल.
• सुरुवात करण्यासाठी एक रिपॉझिटरी आणि एक चॅनेल बाइंड करा. रनर अशा कोणत्याही रनला नाकारतो ज्याचे प्रोजेक्ट टार्गेट त्याच्या स्थानिक 'allowlist' च्या बाहेर असते, त्यामुळे अनबाउंड रिपॉझिटरी एजंटला स्वतःमध्ये ओढू शकत नाही.
• कमेंटिंग टोकनला कोणत्याही 'apply' टोकनपासून वेगळे ठेवा, जेणेकरून 'write access' रद्द केल्यास 'triage' प्रक्रिया बंद पडणार नाही.

चुकीच्या दिशेने जाणाऱ्या रनसाठी Slack कडे /stop कमांड आहे. प्रत्येक रन एक ऑडिट रेकॉर्ड देखील मागे सोडते ज्यामध्ये ते मेंशन असते ज्याने रन सुरू केली आणि एजंटने काय केले, जे तुम्ही नंतर वाचून कुठे चूक झाली हे शोधू शकता.

सामाजिक बाजू कॉन्फिगरेशनइतकीच महत्त्वाची आहे. बॉटला अशा एका चॅनेलमध्ये ठेवा जिथे लोक मशीनकडून अपेक्षा ठेवतात आणि त्यांना माहित असते की ते चुकीचे असू शकते. चाळीस लोकांच्या चॅनेलमध्ये आत्मविश्वासाने दिलेले चुकीचे उत्तर, ज्यांना वाटते की एखाद्या मानवाने त्याचे पुनरावलोकन केले आहे, ते वाचवलेल्या 'triage' वेळेपेक्षा जास्त महाग पडते. चॅनेलच्या वर्णनात बॉटचा मालक कोण आहे आणि त्याचे आउटपुट कोण तपासते, हे लिहा.

बॅकअप, अपग्रेड आणि पिनिंग

सर्व डेटा दोन पाथमध्ये साठवला जातो: /home/opentag/.config/opentag/config.json आणि /home/opentag/.local/state/opentag. पहिल्या पाथमध्ये तुमचे क्रेडेंशियल्स असतात, तर दुसऱ्यामध्ये रन हिस्ट्री आणि डेटाबेस फाईल असते. या दोन्हीचा बॅकअप घ्या, त्यांना 600 मोडमध्ये ठेवा आणि सर्व्हरच्या बाहेर सुरक्षित ठिकाणी साठवा. हे गमावल्यास तुम्हाला टोकन्स आणि बाइंडिंग्स पुन्हा तयार करावे लागतील, मात्र सर्व्हर पुन्हा बिल्ड करण्याची गरज पडणार नाही.

अपग्रेड म्हणजे व्हर्जन अपडेट करणे आणि सर्व्हिस रीस्टार्ट करणे होय.

sudo npm install -g @opentag/cli@0.9.0
sudo -iu opentag opentag service stop
sudo -iu opentag opentag service start
sudo -iu opentag opentag doctor

@latest ट्रॅक करण्याऐवजी व्हर्जन पिन करा. हे सॉफ्टवेअर तुमच्या रिपॉझिटरीवर लाइव्ह टोकन वापरून कोडिंग एजंट चालवते, त्यामुळे रात्रीच्या वेळी प्रकाशित झालेली कोणतीही नवीन रिलीज तुमच्यासाठी एक अनरीव्ह्यू केलेली (तपासली नसलेली) बदल ठरू शकते. सुरक्षा धोरणानुसार जुन्या व्हर्जनसाठी बॅकपोर्ट्स दिले जात नाहीत आणि सुधारणा फक्त नवीन रिलीजमध्येच उपलब्ध असतात. त्यामुळे पिनिंगचा अर्थ असा आहे की तुम्ही चेंजलॉग वाचून जाणीवपूर्वक अपडेट करता. याचा अर्थ असा नाही की तुम्ही कायम v0.9.0 वरच राहिले पाहिजे. जुलै 2026 पर्यंतचा इतिहास पाहता, दरमहा अनेक रिलीज येत आहेत, त्यामुळे प्रत्येक अपडेटपूर्वी रिलीज नोट्स वाचणे आवश्यक आहे.

FAQ

OpenTag चालवण्यासाठी मला VPS ची गरज आहे का, की लॅपटॉप पुरेसा आहे?

केवळ Slack साठी लॅपटॉप पुरेसा आहे, कारण Socket Mode एक आउटबाउंड WebSocket उघडतो आणि त्याला कोणत्याही इनबाउंड पोर्टची गरज नसते. GitHub ची परिस्थिती वेगळी आहे. रिपॉझिटरी वेबहुक्स इनबाउंड HTTP द्वारे तुम्ही नोंदणी केलेल्या URL वर पाठवले जातात, त्यामुळे तो पत्ता कायमस्वरूपी स्थिर असणे आणि तुम्ही झोपलेले असतानाही प्रतिसाद देणे आवश्यक असते. मोफत खात्यावरील टनेल होस्ट प्रत्येक रीस्टार्टनंतर बदलतो आणि GitHub जुन्या पत्त्यावरच माहिती पाठवत राहते, ज्यामुळे रिपॉझिटरीच्या Recent Deliveries टॅबमध्ये अपयशी नोंदी दिसतात आणि थ्रेडमध्ये कोणतीही हालचाल होत नाही. स्थिर DNS नाव आणि प्रमाणपत्र असलेला VPS या दोन्ही समस्या दूर करतो.

OpenTag ला GitHub च्या कोणत्या परवानग्यांची गरज असते?

Only select repositories पर्यंत मर्यादित असलेला एक फाइन-ग्रेन्ड पर्सनल ॲक्सेस टोकन, ज्यामध्ये Issues: Read and write आणि Pull requests: Read and write या परवानग्या असाव्यात. यामुळे उल्लेख वाचणे आणि थ्रेडमध्ये उत्तर देणे शक्य होते. जोपर्यंत तुम्ही preparePullRequestBranch ला true करत नाही, तोपर्यंत कोडसाठी राइट ॲक्सेसची गरज नसते. जर तुम्ही preparePullRequestBranch true केले, तर OpenTag ब्रांचेस पुश करू शकतो. कोड लिहिण्यासाठीचा टोकन आणि कमेंट करण्यासाठीचा टोकन वेगळा ठेवण्यासाठी स्वतंत्र githubApplyToken उपलब्ध आहे. सर्व रिपॉझिटरीजचा राइट ॲक्सेस असलेला टोकन वापरणे टाळा, कारण अशा रिपॉझिटरीजवर कमेंट करू शकणारी कोणतीही व्यक्ती कमिट करू शकणाऱ्या एजंटला नियंत्रित करू शकते.

चुकीच्या दिशेने जाणारा रन मी कसा थांबवू?

Slack मध्ये यासाठी एक /stop कमांड आहे. सर्व्हरवर, opentag status काय चालू आहे हे दर्शवते आणि opentag service stop डेमनला थांबवते, ज्यामुळे एका रनऐवजी संपूर्ण पाइपलाइन बंद होते. या दोन्हीची गरज पडू नये म्हणून, approvalMode ला ask वर सेट करा जेणेकरून काहीही बदलण्यापूर्वी रन मानवी हस्तक्षेपासाठी थांबेल. तसेच preparePullRequestBranch ला false ठेवा, जेणेकरून चुकीचा रन ब्रांच तयार करण्याऐवजी फक्त एक कमेंट करेल.

माझा वेबहूक 502 एरर का देतोय आणि थ्रेड शांत का आहे?

502 एरर nginx कडून येतो, OpenTag कडून नाही. याचा अर्थ असा की प्रॉक्सी लिसनरपर्यंत पोहोचू शकत नाही. /var/log/nginx/error.log कमांड connect() failed (111: Connection refused) while connecting to upstream दर्शवेल. एकतर लिसनर थांबलेला आहे किंवा तो proxy_pass ओळीत नमूद केलेल्या पोर्टपेक्षा वेगळ्या पोर्टवर आहे. sudo ss -tlnp रन करा आणि GitHub साठी 127.0.0.1:3050 वर आणि Slack साठी 127.0.0.1:3040 वर काहीतरी लिसन करत असल्याची खात्री करा, त्यानंतर बाइंडिंग्स आणि एक्झिक्युटर्ससाठी opentag doctor रन करा.