OpenTag-ஐ உங்கள் VPS-ல் சுயாதீனமாக இயக்குவது எப்படி?

ஒரு ஏஜென்ட்டை நீங்கள் குறிப்பிடும்போது OpenTag என்ன செய்கிறது

Slack thread அல்லது GitHub issue-ல் நீங்கள் ஒரு @mention-ஐப் பயன்படுத்தும்போது, OpenTag அதை உங்கள் சொந்த machine-ல் இயங்கும் ஒரு coding agent-ஆக மாற்றுகிறது. யாராவது ஒரு issue-ல் @opentag investigate this என்று comment செய்கிறார்கள். ஒரு listener அந்த platform event-ஐப் பெற்று, அதன் signature-ஐச் சரிபார்த்து, அந்த mention-ஐ அதனுடன் இணைக்கப்பட்ட project-உடன் பொருத்தி, local checkout-ல் ஒரு coding agent-ஐத் தொடங்கி, அதன் முடிவை அதே thread-ல் பதிவிடுகிறது.

இந்த project MIT உரிமம் பெற்றது மற்றும் amplifthq/opentag-ல் உள்ளது. ஆகஸ்ட் 2026 நிலவரப்படி, புதிய tagged release v0.9.0 ஆகும். இது 28 ஜூலை 2026 அன்று வெளியிடப்பட்டது, மேலும் இது ஒரு npm package-ஆகக் கிடைக்கிறது. இதற்கு அதிகாரப்பூர்வ container image இல்லை, எனவே நீங்கள் pin செய்வது npm version-ஐத்தான். கீழே உள்ள ஒவ்வொரு கட்டளையும் அதைத்தான் pin செய்கிறது.

GitHub-ன் செயல்பாட்டினால், இது ஒரு laptop project-ஆக இல்லாமல் VPS project-ஆக மாறுகிறது. GitHub, நீங்கள் ஒருமுறை பதிவு செய்யும் URL-க்கு HTTP request அனுப்புவதன் மூலம் repository event-களை வழங்குகிறது. எனவே, அந்த URL நாளைக்கும் அதே முகவரியில் பதிலளிக்க வேண்டியது அவசியம்.

நான்கு முக்கிய செயல்பாட்டுப் பகுதிகள்

The listener தள நிகழ்வுகளைப் (platform events) பெறுகிறது; ஒவ்வொரு தளத்திற்கும் தனித்தனி listener உண்டு. GitHub listener என்பது /github/webhooks பாதையில் 3050 port-ல் இயங்கும் ஒரு HTTP endpoint ஆகும். Slack Events API listener 3040 port-ல் /slack/events பாதையில் இயங்குகிறது. Slack-ஐ Socket Mode-லும் இயக்கலாம்; இதில் application ஒரு outbound WebSocket-ஐத் திறக்கும், எனவே inbound port எதும் தேவையில்லை.

The dispatcher ஒரு ஒருங்கிணைப்பாளர். இது இயல்பாக 3030 port-ல் இயங்குகிறது, OPENTAG_DATABASE_PATH மூலம் குறிப்பிடப்படும் local database கோப்பில் run state-ஐப் பராமரிக்கிறது, மேலும் ஒவ்வொரு run-க்கும் ஒரு audit trail-ஐப் பதிவு செய்கிறது. பெட்டிக்கு (box) வெளியே உள்ள எந்தவொரு சேவையும் இந்த port-ஐ அணுகக்கூடாது.

The runner ஒரு local daemon ஆகும். இது பணிக்காகத் தொடர்ந்து காத்திருந்து (polls), ஒரு run-ஐக் கைப்பற்றி, அதன் மீது lease-ஐ வைத்திருக்கும். run செயல்பாட்டில் இருக்கும் வரை, இயல்பாக ஒவ்வொரு 15 வினாடிகளுக்கும் ஒரு heartbeat-ஐ அனுப்பும். ஒரு run-ன் project target விடுபட்டிருந்தாலோ அல்லது அதன் config-ல் உள்ள allowlist-க்கு வெளியே இருந்தாலோ, அந்த run-ஐ இது நிராகரிக்கும். நீங்கள் இணைக்காத ஒரு repository-க்கு GitHub நிகழ்வு உங்கள் agent-ஐத் திசைதிருப்புவதைத் தடுக்கும் சோதனை இதுவே.

The executor என்பது coding agent ஆகும். OpenTag இதை ACP (agent client protocol) மூலம் இயக்குகிறது. இது standard input மற்றும் output வழியாகப் பேசும் ஒரு JSON-RPC protocol ஆகும். OpenTag வழங்கும் working directory-க்குள் ஒரு child process-ஆக இந்த agent இயங்குகிறது. உள்ளமைக்கப்பட்ட (built-in) பெயர்களில் echo, codex, claude-code, cursor, opencode, hermes மற்றும் openclaw ஆகியவை அடங்கும். echo-உடன் தொடங்கவும்; இதுவே example config-ல் வழங்கப்பட்ட executor ஆகும். ஒரு model உங்கள் code-ஐத் தொடுவதற்கு முன்பே, முழுப் பாதையும் சரியாகச் செயல்படுகிறதா என்பதை இது உறுதிப்படுத்துகிறது.

இதன் வரிசை எப்போதும் மாறாது: platform event, signature check, run record, claim, agent, reply in the thread.

ஏன் ஒரு மடிக்கணினியும் tunnel-ம் மட்டும் போதுமானதல்ல

GitHub அமைப்பு வழிகாட்டி ngrok http 3050-ஐ இயக்கி, அந்த tunnel host-ஐ repository webhook-ல் பதிவிடுமாறு கூறுகிறது. இது முதல் பத்து நிமிடங்களுக்கு மட்டுமே வேலை செய்யும். ஒரு இலவச tunnel host, process restart ஆகும்போதெல்லாம் மாறிவிடும்; மடிக்கணினி sleep mode-க்குச் சென்றால் அது செயலிழந்துவிடும். GitHub பழைய payload URL-ஐயே வைத்திருப்பதால், அது மீண்டும் மீண்டும் முயற்சிக்கும். இதனால் webhook அமைப்புகளில் உள்ள Recent Deliveries தாவல் தோல்விகளால் நிரம்பும், ஆனால் thread-ல் எந்த பதிலும் இருக்காது. ஒரு webhook வேலை செய்யவில்லை என்றால், அது யாரும் கவனிக்காத bot போலவே தோற்றமளிக்கும் என்பதால், ஒரு வாரம் வரை இதைக் யாரும் கவனிக்க மாட்டார்கள்.

ஒரு VPS இந்த இரண்டு சிக்கல்களையும் சரிசெய்கிறது. DNS பெயர் மாறாது என்பதால், நீங்கள் ஒருமுறை பதிவிடும் payload URL எப்போதும் சரியாக இருக்கும். அந்த machine sleep mode-க்குச் செல்லாது என்பதால், 02:00 மணிக்கு வரும் comment-க்கும் பதில் கிடைக்கும். முதலில் அந்த server-ஐச் சரியாக அமைக்கவும்: புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற பகுதி, இந்த வழிகாட்டியில் கருதப்படும் login user மற்றும் firewall பற்றிய தகவல்களை வழங்குகிறது.

Slack இதற்கு விதிவிலக்கு. Socket Mode-ல் அது வெளிநோக்கி இணைப்பை ஏற்படுத்துவதால் public URL தேவையில்லை; எனவே Slack-ஐ மட்டும் பயன்படுத்தும் deployment-ஐ மூடியே வைத்திருக்கலாம். GitHub-ல் இதற்கு இணையான வசதி இல்லை. Repository webhooks என்பவை inbound HTTP ஆகும். இதற்கு ஒரு public endpoint தேவை, அதாவது TLS (transport layer security) மற்றும் signature சரிபார்ப்பு அவசியம்.

Ubuntu-வில் pinned release மூலம் OpenTag-ஐ self-host செய்தல்

OpenTag v0.9.0 பதிப்பிற்கு Node.js 22 அல்லது அதற்குப் பிந்தைய பதிப்பு தேவை. Ubuntu 24.04 அதன் சொந்த repository-ல் 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 தொடங்கும்போது தோல்வியடையலாம்.

இந்த service-க்கு எனத் தனி பயனர் கணக்கை உருவாக்கவும். இந்த agent அந்தப் பயனரின் அனுமதியுடன் இயங்குவதால், இது உங்கள் login கணக்காகவோ அல்லது root கணக்காகவோ இருக்கக்கூடாது. VPS-ல் குறைந்தபட்ச அதிகாரமுள்ள பயனர்கள் என்ற பகுதியில் இதற்கான காரணங்கள் விளக்கப்பட்டுள்ளன.

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 அதன் background service-ஐ systemd மூலம் நிறுவுகிறது, linger வசதி இல்லையெனில் உங்கள் SSH session முடிந்தவுடன் user service-ம் நின்றுவிடும்.

அந்தப் பயனராகவே setup-ஐ இயக்கவும்.

sudo -iu opentag opentag setup

Setup ஆறு கேள்விகளைக் கேட்கும்: CLI மொழி, local listening address, coding agent, பணிபுரிய வேண்டிய local project, சேமிக்க வேண்டிய platform credentials, மற்றும் இயக்கும் முறை. Listening address-ஐ 127.0.0.1-லேயே வைத்திருக்கவும், ஏனெனில் nginx TLS termination செய்து இதற்கு forward செய்யும், எனவே listeners வெளிப்புறத்திலிருந்து அணுகக்கூடியதாக இருக்க வேண்டிய அவசியமில்லை. GitHub-க்கு, இது owner/repo வடிவத்தில் repository, pull requests திறக்க அனுமதி, webhook port (இயல்பாக 3050) மற்றும் token ஆகியவற்றைக் கேட்கும். இறுதியில் background service mode-ஐத் தேர்ந்தெடுக்கவும். உங்களிடம் ஏற்கனவே config கோப்பு இருந்து, கேள்விகள் இன்றி service-ஐ நிறுவ விரும்பினால், opentag setup --service கட்டளையைப் பயன்படுத்தவும்.

Config கோப்பு /home/opentag/.config/opentag/config.json-லும், runtime state /home/opentag/.local/state/opentag-லும் அமையும். Setup கோப்பை எழுதிய பிறகு, இந்தத் தரவுகளை நீங்களே சரிபார்ப்பது நல்லது.

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

பழைய shared pairingToken-ஐ விட, runner-scoped bearer token ஆன runnerToken-ஐப் பயன்படுத்தவும். Config கோப்பில் credentials plain text-ஆக இருக்கும்; அவற்றை secret reference மூலம் மாற்றினால், startup-ன் போது environment அல்லது disk-ல் உள்ள கோப்பிலிருந்து மதிப்பு எடுக்கப்படும். எதுவாக இருந்தாலும், இந்தக் கோப்புதான் server-ல் மிகவும் முக்கியமான பாதுகாப்பு அம்சம்: mode 600-ல் இருக்க வேண்டும், opentag-க்குச் சொந்தமாக இருக்க வேண்டும், மேலும் git repository-க்குள் ஒருபோதும் இருக்கக்கூடாது. இது குறித்த விரிவான விவாதம் AI agents-ல் ரகசியங்களை எவ்வாறு பாதுகாப்பது என்ற பகுதியில் உள்ளது.

எதையும் பொதுவெளியில் வெளிப்படுத்தும் முன் நிறுவலைச் சரிபார்க்கவும்.

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

opentag doctor கட்டளை dispatcher, bindings, checkouts மற்றும் executors ஆகியவற்றைச் சரிபார்க்கும். opentag status கட்டளை config மற்றும் runtime state-ஐக் காட்டும், runs இருக்கும்போது ஒரு குறிப்பிட்ட run-க்கு மட்டும் இதைச் சுருக்கலாம். doctor அறிக்கையிடும் அனைத்துப் பிழைகளையும் சரிசெய்த பின்னரே, ஒரு platform-ஐ இந்த server-டன் இணைக்கவும்.

TLS-ஐ முன்னால் வைத்து இரண்டு பாதைகளை மட்டும் திறக்கவும்

Nginx TLS-ஐ முடித்துவிட்டு, சரியாக இரண்டு பாதைகளை மட்டும் முன்னோக்கி (forward) அனுப்புகிறது. மற்ற அனைத்தும் 404 பிழையைத் தரும், எனவே host-ஐ ஸ்கேன் செய்பவர்களுக்குப் பின்னால் என்ன இயங்குகிறது என்பது தெரியாது.

/etc/nginx/sites-available/opentag-ல் ஒரு சாதாரண port 80 server block-ஐ கீழே உள்ள இரண்டு locations-உடன் எழுதவும், பிறகு 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 ஆகியவற்றை அச்சிடுகிறது, இது தட்டச்சுப் பிழைக்கும், தளத்தை முடக்கும் reload-க்கும் இடையில் உள்ள ஒரே பாதுகாப்பு ஆகும். Ubuntu 24.04-ல் nginx உடன் Certbot என்பது புதுப்பித்தல் மற்றும் ACME (automatic certificate management environment) சவால் தோல்வியடையும் வழிகளைப் பற்றி விளக்குகிறது. முடிக்கப்பட்ட block இதோ.

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), மேலும் port-க்கு பின்னால் எதுவும் இல்லாத proxy_pass, அசல் URI-ஐ மாற்றமின்றி கடத்துகிறது. =-ஐ நீக்கினால், /github/webhooks/-க்கு கீழ் உள்ள ஒவ்வொரு பாதையும் முன்னோக்கி அனுப்பப்படும், இது listener-க்குத் தேவையானதை விட அதிகப்படியான பரப்பளவாகும்.

Firewall குறுகியதாகவே இருக்க வேண்டும்.

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

Ports 3030, 3040 மற்றும் 3050 ஒருபோதும் திறக்கப்படாது. அவை அனைத்து interface-களிலும் இல்லாமல், loopback-ல் மட்டுமே பிணைக்கப்பட்டுள்ளதா என்பதை உறுதிப்படுத்தவும்.

sudo ss -tlnp

ஒவ்வொரு OpenTag வரியும் 127.0.0.1:3030 அல்லது அது போன்றதாக இருக்க வேண்டும். 0.0.0.0:3050 என்று ஒரு வரி இருந்தால், listener தன்னை முழு இணையத்திற்கும் வழங்குகிறது என்று அர்த்தம், ufw மட்டுமே அதைத் தடுக்கிறது. இது ஒரு firewall தவறு நடந்தால், open agent trigger-க்கு வழிவகுக்கும். ufw firewall அடிப்படைகள் என்பது அந்த default deny உண்மையில் என்ன செய்கிறது என்பதை விளக்குகிறது.

இரண்டு சோதனைகள் முன் கதவை உறுதிப்படுத்துகின்றன. curl -I https://opentag.example.com/ என்பது Nginx-லிருந்து 404-ஐத் தருகிறது, இது certificate செல்லுபடியாகும் என்பதையும், catch-all மூடப்பட்டிருப்பதையும் காட்டுகிறது. கையொப்பம் இல்லாத /slack/events அல்லது /github/webhooks-க்கான கோரிக்கை ஒருபோதும் 200-ஐத் தரக்கூடாது.

ஒவ்வொரு கையொப்பத்தையும் சரிபார்க்கவும், ஏனெனில் URL பொதுவானது

Payload URL-ஐ எவர் வேண்டுமானாலும் கண்டறிய முடியும். இது உங்கள் repository அமைப்புகள், browser history, அல்லது ஒரு ticket-ல் ஒட்டப்பட்ட screenshot ஆகியவற்றில் இருக்கலாம். GitHub-லிருந்து வரும் உண்மையான delivery-க்கும், யாரோ ஒருவர் கையால் தட்டச்சு செய்த கோரிக்கைக்கும் இடையே உள்ள ஒரே வித்தியாசம் இந்த கையொப்பம் (signature) மட்டுமே.

GitHub ஒவ்வொரு delivery-யையும் webhook secret கொண்டு கையொப்பமிட்டு, அதன் முடிவை x-hub-signature-256 header-ல் அனுப்புகிறது. OpenTag அந்த header-ஐ platforms.github.webhookSecret-உடன் ஒப்பிட்டு சரிபார்க்கிறது. திட்டத்தின் பாதுகாப்பு குறிப்புகள் (hardening notes) இந்த விதியை நேரடியாகக் கூறுகின்றன: /github/webhooks-ல் கையொப்பமிடப்படாத source events-ஐ ஏற்க வேண்டாம். Slack ஒவ்வொரு கோரிக்கையையும் SLACK_SIGNING_SECRET கொண்டு கையொப்பமிட்டு, ஒரு timestamp-ஐயும் சேர்க்கிறது; எனவே, கைப்பற்றப்பட்ட ஒரு body-ஐ பல மணிநேரம் கழித்து மீண்டும் இயக்க (replay) முடியாது.

இதை தவிர்ப்பது சிறிய ஆபத்து அல்ல. சரிபார்க்கப்படாத endpoint, கையால் எழுதப்பட்ட issue_comment payload-ஐ ஏற்கும். அதில் @opentag இருக்கலாம். அப்போது OpenTag உங்கள் token-ஐப் பயன்படுத்தி, உங்கள் checkout-ல், ஒரு அந்நியரின் அறிவுறுத்தலின்படி coding agent-ஐ இயக்கும். அந்தப் போலி payload குறிப்பிடும் எந்தவொரு thread-க்கும் பதில் அனுப்பப்படும்.

OpenTag இதற்கு மேல் இரண்டு அடுக்குகளைச் சேர்க்கிறது. Source deliveries, delivery ID மூலம் கண்காணிக்கப்படுகின்றன. எனவே, ஒரே event-ஐ மீண்டும் அனுப்புவது இரண்டாவது run-ஐத் தொடங்காது. Runner அழைப்புகள் idempotency keys-ஐ ஏற்கும். எனவே, ஒன்றை மீண்டும் இயக்கினால், கூடுதல் audit event-ஐச் சேர்க்காமல் வெற்றி என்ற பதிலை மட்டுமே தரும்.

Rate limits-ஐ உள்ளமைக்க முடியும், அவற்றைச் செயல்படுத்த வேண்டும். OPENTAG_RATE_LIMIT_WINDOW_MS மற்றும் OPENTAG_RATE_LIMIT_MAX_REQUESTS ஆகியவை கோரிக்கை விகிதத்தைக் கட்டுப்படுத்துகின்றன. OPENTAG_MAX_REQUEST_BODY_BYTES body-யின் அளவைக் கட்டுப்படுத்துகிறது. அளவுக்கதிகமான payload வந்தால், அது 413 request_body_too_large மூலம் நிராகரிக்கப்படும். OPENTAG_RATE_LIMIT_DISABLED=true உள்ளூர் மேம்பாட்டிற்காக (local development) மட்டுமே உள்ளது; பொதுவான server-ல் இதற்கு இடமில்லை. அதே குறிப்புகளிலிருந்து மற்றொரு விதி: ஒரு பொதுவான relay URL கண்டிப்பாக HTTPS-ஐப் பயன்படுத்த வேண்டும். CLI, localhost-க்கு மட்டுமே plain HTTP-ஐ அனுமதிக்கிறது.

போட் (bot) உண்மையில் என்னென்ன token scopes-ஐக் கொண்டிருக்க வேண்டும்?

GitHub-ல், OpenTag ஒரு GitHub App-க்கு பதிலாக fine-grained personal access token-ஐப் பயன்படுத்துகிறது. App வழிமுறை திட்டமிடப்பட்டுள்ளதாகவும், தற்போதைய CLI அமைப்பில் அது இயல்பானதல்ல என்றும் ஆவணங்கள் கூறுகின்றன. இதனால் ஒரு முக்கியமான விளைவு ஏற்படுகிறது: அந்த token-ஐ உருவாக்கிய நபரின் பெயரிலேயே போட் கருத்துகளை (comments) பதிவிடும். எனவே, ஒவ்வொரு triage பதிலிலும் அந்த நபரின் பெயர் இடம்பெறுவதை நீங்கள் விரும்பும் ஒரு கணக்கின் கீழ் இதை உருவாக்கவும்.

அமைவு வழிகாட்டி (setup guide) பரிந்துரைப்பது போலவே, மிகக் குறைந்த அளவிலான அனுமதிகளை மட்டும் வழங்கவும். Only select repositories என்பதைத் தேர்ந்தெடுத்து, ஒரு repository-ஐ மட்டும் தேர்வு செய்யவும். Issues: Read and write மற்றும் Pull requests: Read and write ஆகிய அனுமதிகளை வழங்கவும். ஒரு mention-ஐப் படித்து, அந்த thread-ல் பதிலளிக்க இது போதுமானது.

எது விடுபட்டுள்ளது என்பதைக் கவனிக்கவும்: code-க்கான write access வழங்கப்படவில்லை. preparePullRequestBranch என்பது true என அமைக்கப்பட்டால் ஒழிய, OpenTag புதிய branch-களை push செய்யாது. மேலும், githubApplyToken தனியாக இருப்பதால், code-ஐ எழுதும் token-ம், கருத்துகளைப் பதிவிடும் token-ம் வெவ்வேறானவை. இவற்றைத் தனித்தனியாக வைத்திருங்கள். read-and-comment செயல்முறை சில வாரங்களுக்குச் சரியாக இயங்கும் வரை, write token-ஐப் பயன்படுத்த வேண்டாம்.

All repositories முழுமைக்கும் Contents: Read and write அனுமதி கொண்ட token-ஐ உருவாக்குவதைத் தவிர்க்க வேண்டும். அந்த repository-களில் கருத்து தெரிவிக்கக்கூடிய எவரும், commit உரிமைகள் கொண்ட ஒரு முகவரை (agent) கட்டுப்படுத்த முடியும்; மேலும், தணிக்கை பதிவுகளில் (audit trail) அந்த token-ன் உரிமையாளரே அதைச் செய்ததாகக் காட்டும். முகவர் நம்பகத்தன்மையைப் பெற்ற பிறகு, ஒவ்வொரு repository-ஆக அனுமதியை விரிவுபடுத்தவும்.

Slack-ல் போட்-க்கான scopes என்பவை app_mentions:read, chat:write, reactions:write மற்றும் channels:history ஆகும். Private channels-க்கு groups:history அனுமதியும், message.groups event-க்கான சந்தாவும் (subscription) தேவை. Socket Mode-க்கு connections:write கொண்ட app-level token தேவை, இது xapp- என்பதில் தொடங்கும். channels:history என்பது போட் சேர்க்கப்பட்டுள்ள public channels-ன் செய்தி வரலாற்றைப் படிக்கும். எனவே, எல்லா இடங்களிலும் சேர்க்காமல், எந்தெந்த channels-ல் போட் தேவையோ அங்கு மட்டும் சேர்க்கவும்.

ஒரு சிக்கலை முழுமையாக வழிநடத்துதல்

முதலில் webhook-ஐ அமைக்க வேண்டும். Repository-ல் Settings பகுதிக்குச் சென்று, Webhooks-ஐத் திறந்து, Add webhook என்பதைக் கிளிக் செய்யவும். Payload URL என்பது https://opentag.example.com/github/webhooks, content type என்பது application/json, மற்றும் secret என்பது setup மூலம் உருவாக்கப்பட்டதாகும். Issue comments மற்றும் Pull request review comments ஆகியவற்றை மட்டும் தேர்வு செய்யவும்.

நீங்கள் சேமித்தவுடன் GitHub ஒரு ping delivery-ஐ அனுப்பும். Recent Deliveries-ஐத் திறந்து, கோரிக்கை server-ஐ அடைந்துள்ளதா என்று சரிபார்க்கவும். அங்கு 502 பிழை இருந்தால், listener-ஐ அடைய முடியவில்லை என்று Nginx கூறுகிறது; இது GitHub தொடர்பான சிக்கல் அல்ல, உள்ளூர் சிக்கல்.

இப்போது இதைப் பயன்படுத்தவும். ஒரு பிழையை விவரிக்கும் issue-ஐத் திறந்து, பின்வருமாறு comment செய்யவும்:

@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 delivery, 2xx response-உடன் பதிவாகும். Dispatcher ஒரு run-ஐப் பதிவு செய்யும். Runner அதை ஏற்றுக்கொண்டு heartbeating-ஐத் தொடங்கும். Executor checkout-ஐத் திறந்து பணியைத் தொடங்கும். பதில் அதே issue thread-ல் comment-ஆக வரும். sudo -iu opentag opentag status, run செயல்பாட்டில் இருக்கும்போது அதைக் காட்டும், எனவே நீங்கள் யூகிக்கத் தேவையில்லை, நேரடியாகக் கண்காணிக்கலாம்.

முதல் உண்மையான run-க்கு முன்னதாக approvalMode-ஐ ask என அமைக்கவும். ask பயன்முறையில், நிலையை மாற்றும் எந்தவொரு செயலையும் செய்வதற்கு முன்பு, run இடைநிறுத்தப்பட்டு ஒரு நபரின் ஒப்புதலுக்காகக் காத்திருக்கும். auto மற்றும் autonomous பயன்முறைகளும் உள்ளன; ஒரு மாத கால உரையாடல்களைப் படித்து முடித்த பிறகு, repository-ல் இவற்றைத் தாராளமாகப் பயன்படுத்தலாம்.

Slack பக்கத்தில், அதே run சேனலில் /bind owner/repo உடன் தொடங்கி, ஒரு mention-உடன் தொடரும். Bot /help, /status, /doctor, /stop மற்றும் /unbind confirm ஆகியவற்றுக்கும் பதிலளிக்கும். OPENTAG_SLACK_BINDING_ADMIN_USER_IDS மூலம் bindings-ஐ மாற்றக்கூடிய நபர்களைக் கட்டுப்படுத்தவும். இது Slack user ID-களின் கமா-பிரிக்கப்பட்ட பட்டியல் ஆகும், ஏனெனில் binding என்பது பொதுச் சேனலுக்கும் உங்கள் server-ல் உள்ள checkout-க்கும் இடையிலான இணைப்பாகும்.

Triage ஒரு சிறந்த தொடக்க வழி, ஏனெனில் இது தரவுகளைப் படிக்கும், மாற்றங்களைச் செய்யாது, மேலும் பதிலின் தரத்தை மதிப்பிடுவது எளிது. அடுத்த கட்டம் Review ஆகும், இதில் agent issue-க்கு பதிலாக diff-ல் comment செய்யும்: சுயமாக இயங்கும் pull request review agent என்பது pull request-களைக் கையாளும் இதே கட்டமைப்பைக் கொண்டது. Agent பணிபுரியும் போது உங்கள் சொந்த system-களை அணுக வேண்டும் எனில், அதற்கு VPS-ல் உள்ள MCP servers தேவைப்படும். Triage அடிக்கடி கேட்கும் மற்றொரு திறன் Web search ஆகும், உங்கள் சொந்த SearXNG instance-ஐ agent-உடன் இணைப்பது அந்தத் தேடல்களை உங்கள் வன்பொருளிலேயே வைத்திருக்க உதவும், ஆனால் அந்நியரின் உரை agent-ஐச் சென்றடைய மற்றொரு வழி உருவாகும் என்பதை நினைவில் கொள்ளவும்.

அனைவருக்கும் முன்னால் ஏஜென்ட் தவறான தகவலை அளித்தால் என்ன நடக்கும்?

அது தவறாகவே இருக்கும். ஆனால், அதனால் ஏற்படும் பாதிப்பு என்ன என்பதே கேள்வி.

பொதுவெளியில் ஒரு சிக்கலுக்குத் தவறான பதில் அளிக்கப்பட்டால், அது உங்கள் குழுவினர் அறிந்த பெயரில் பதிவிடப்படும். அது பதிவிடப்பட்ட கணமே, சந்தா செலுத்திய அனைவருக்கும் GitHub மின்னஞ்சல் அனுப்பிவிடும். அந்தப் பதிவை நீக்கினாலும், சென்ற மின்னஞ்சலைத் திரும்பப் பெற முடியாது. Slack அறிவிப்புக்கும் இதுவே பொருந்தும். ஏஜென்ட் தனிப்பட்ட முறையில் சரியாகச் செயல்படுவதை விட, பொதுவெளியில் தவறாகச் செயல்பட வாய்ப்புள்ளது என்பதைக் கருத்தில் கொண்டு திட்டமிடுங்கள்.

பாதிப்பைக் குறைக்க நான்கு வழிகள் உள்ளன. நீங்கள் எழுதும் எந்தவொரு prompt-ஐ விடவும் இவை முக்கியமானவை:

• ask முறையில் இயக்கவும். இதன் மூலம் ஏஜென்ட் ஒரு திட்டத்தைப் பரிந்துரைக்கும், ஒரு நபர் அதை அங்கீகரிப்பார். ஒரு தவறான திட்டத்தால் ஒரு கிளிக் மட்டுமே வீணாகும்.
• preparePullRequestBranch-ஐ அதன் இயல்புநிலையான false-லேயே வைத்திருக்கவும். இதனால், ஒரு தவறான செயல்பாட்டின் மோசமான விளைவு, தவறான branch-ஆக மாறாமல், தவறான கருத்தாக மட்டுமே இருக்கும்.
• தொடங்குவதற்கு ஒரு repository மற்றும் ஒரு channel-ஐ மட்டும் இணைக்கவும். ஒரு runner, அதன் local allowlist-க்கு வெளியே உள்ள project-ஐ இலக்காகக் கொண்ட எந்தவொரு செயல்பாட்டையும் நிராகரிக்கும். எனவே, இணைக்கப்படாத repository-ஆல் ஏஜென்ட்டைத் தன்வசப்படுத்த முடியாது.
• கருத்து தெரிவிப்பதற்கான token-ஐ, மாற்றங்களைச் செயல்படுத்துவதற்கான (apply) token-லிருந்து தனித்தனியாக வைத்திருக்கவும். இதனால், எழுதும் அனுமதியை (write access) ரத்து செய்வது triage செயல்பாட்டைப் பாதிக்காது.

தவறான பாதையில் செல்லும் ஒரு செயல்பாட்டை நிறுத்த Slack-ல் /stop கட்டளை உள்ளது. ஒவ்வொரு செயல்பாடும் ஒரு தணிக்கைப் பதிவை (audit record) உருவாக்கும். அதில் அந்தச் செயல்பாட்டைத் தொடங்கிய குறிப்பும், ஏஜென்ட் என்ன செய்தது என்பதும் இருக்கும். எங்கே தவறு நடந்தது என்பதைக் கண்டறிய இதைப் படித்துப் பார்க்கலாம்.

தொழில்நுட்ப அமைப்பைப் போலவே சமூகப் பாதிப்பும் முக்கியமானது. இயந்திரம் செயல்படும் என்று மக்கள் எதிர்பார்க்கும் மற்றும் அது தவறாகச் செயல்பட வாய்ப்புள்ளது என்பதை அறிந்த ஒரு channel-ல் bot-ஐ வைக்கவும். ஒரு மனிதர் சரிபார்த்திருப்பார் என்று நம்பும் நாற்பது பேர் கொண்ட குழுவில், நம்பிக்கையுடன் ஒரு தவறான பதில் அளிக்கப்படுவது, triage மூலம் மிச்சப்படுத்தப்பட்ட நேரத்தை விட அதிக இழப்பை ஏற்படுத்தும். bot-க்கு யார் பொறுப்பு மற்றும் அதன் வெளியீட்டை யார் சரிபார்க்கிறார்கள் என்பதை channel-ன் விளக்கத்தில் குறிப்பிடவும்.

Backups, upgrades மற்றும் pin

அனைத்து தரவுகளும் இரண்டு பாதைகளில் உள்ளன: /home/opentag/.config/opentag/config.json மற்றும் /home/opentag/.local/state/opentag. முதலாவதில் உங்கள் credentials உள்ளன, இரண்டாவதில் run history மற்றும் database file உள்ளன. இவை இரண்டையும் mode 600 அனுமதியுடன் backup எடுத்து, server-க்கு வெளியே பாதுகாப்பாக வைக்கவும். இவற்றை இழந்தால், tokens மற்றும் bindings-ஐ மீண்டும் உருவாக்க வேண்டியிருக்கும்; ஆனால் server-ஐ முழுமையாக மீண்டும் கட்டமைக்க வேண்டியதில்லை.

Upgrades என்பது version-ஐ உயர்த்தி, service-ஐ restart செய்வதாகும்.

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-ஐத் தொடர்ந்து பின்பற்றுவதற்குப் பதிலாக, ஒரு குறிப்பிட்ட version-ஐ pin செய்யவும். இந்த மென்பொருள் உங்கள் repository-ல் live token-ஐப் பயன்படுத்தி coding agent-ஐ இயக்குகிறது. எனவே, இரவோடு இரவாக வெளியாகும் ஒரு புதிய release, நீங்கள் சரிபார்க்காத மாற்றங்களைக் கொண்டிருக்கலாம். Security policy எதையும் backport செய்வதில்லை; திருத்தங்கள் புதிய release-ல் மட்டுமே கிடைக்கும். எனவே, version-ஐ pin செய்வது என்பது, changelog-ஐப் படித்துவிட்டு, திட்டமிட்டு upgrade செய்வதைக் குறிக்கும். இது v0.9.0-விலேயே எப்போதும் இருக்க வேண்டும் என்று அர்த்தமல்ல. ஜூலை 2026 வரையிலான வரலாற்றைப் பார்த்தால், மாதத்திற்குப் பல releases வருகின்றன. எனவே, ஒவ்வொரு முறை version-ஐ உயர்த்தும் முன்பும் release notes-ஐப் படிப்பது அவசியமாகும்.

FAQ

OpenTag-ஐ இயக்க VPS தேவையா அல்லது மடிக்கணினியே போதுமானதா?

Slack-க்கு மட்டும் மடிக்கணினியே போதுமானது, ஏனெனில் Socket Mode ஒரு outbound WebSocket-ஐத் திறந்து கொள்கிறது, இதற்கு inbound port தேவையில்லை. GitHub இதற்கு மாறானது. Repository webhooks ஒருமுறை நீங்கள் பதிவு செய்யும் URL-க்கு inbound HTTP மூலம் தகவல்களை அனுப்புகிறது. எனவே, அந்த முகவரி மாறாமல் இருக்க வேண்டும் மற்றும் நீங்கள் தூங்கும்போது கூட அது பதிலளிக்க வேண்டும். இலவசக் கணக்கின் tunnel host ஒவ்வொரு முறை restart செய்யும்போதும் மாறிவிடும். GitHub பழைய முகவரிக்குத் தகவல்களை அனுப்ப முயற்சிக்கும், இது repository-ன் Recent Deliveries tab-ல் தோல்வியடைந்த பதிவுகளாகவும், thread-ல் எந்தப் பதிலும் இல்லாமலும் காட்டும். நிலையான DNS பெயர் மற்றும் certificate கொண்ட ஒரு VPS இந்த இரண்டு சிக்கல்களையும் நீக்குகிறது.

OpenTag-க்கு என்னென்ன GitHub அனுமதிகள் தேவை?

Only select repositories என வரையறுக்கப்பட்ட, Issues: Read and write மற்றும் Pull requests: Read and write அனுமதிகளைக் கொண்ட ஒரு fine-grained personal access token தேவை. இது ஒரு mention-ஐப் படித்து thread-ல் பதிலளிக்கப் போதுமானது. நீங்கள் preparePullRequestBranch-ஐ true என அமைத்து OpenTag-ஐ branch-களை push செய்ய அனுமதித்தால் ஒழிய, code-க்கு write access தேவையில்லை. மேலும், code-ஐ எழுதும் token-ஐ கருத்து தெரிவிக்கும் token-லிருந்து தனித்தனியாக வைத்திருக்க githubApplyToken வசதி உள்ளது. அனைத்து repository-களுக்கும் contents write அனுமதி கொண்ட token-ஐத் தவிர்க்கவும், ஏனெனில் அந்த repository-களில் கருத்து தெரிவிக்கக்கூடிய எவரும் commit செய்யக்கூடிய ஒரு agent-ஐக் கட்டுப்படுத்த வாய்ப்புள்ளது.

தவறாகச் செல்லும் ஒரு run-ஐ எப்படி நிறுத்துவது?

Slack-ல் இதற்கெனவே /stop கட்டளை உள்ளது. Server-ல், opentag status தற்போது இயங்குபவற்றைக் காட்டும், மற்றும் opentag service stop daemon-ஐ நிறுத்தும்; இது ஒரு run-ஐ மட்டும் நிறுத்தாமல் முழு pipeline-ஐயும் நிறுத்திவிடும். இரண்டையும் பயன்படுத்த வேண்டிய சூழலைத் தவிர்க்க, approvalMode-ஐ ask என அமைக்கவும், இதனால் எதையும் மாற்றும் முன் ஒரு மனிதரின் ஒப்புதலுக்காக run காத்திருக்கும். மேலும், preparePullRequestBranch-ஐ false என வைக்கவும், இது ஒரு தவறான run-ன் போது branch-ஐ உருவாக்குவதற்குப் பதிலாக ஒரு கருத்தை மட்டும் பதிவிடும்.

thread அமைதியாக இருக்கும்போது ஏன் எனது webhook 502 பிழையைத் தருகிறது?

502 பிழை OpenTag-லிருந்து வராமல், nginx-லிருந்து வருகிறது. இதன் பொருள் proxy-ஆல் listener-ஐ அடைய முடியவில்லை என்று அர்த்தம். /var/log/nginx/error.log கட்டளையைப் பயன்படுத்தினால் connect() failed (111: Connection refused) while connecting to upstream-ஐக் காட்டும். listener நிறுத்தப்பட்டிருக்கலாம் அல்லது proxy_pass வரியில் குறிப்பிடப்பட்டுள்ள port-ல் அது இயங்காமல் இருக்கலாம். sudo ss -tlnp கட்டளையை இயக்கி, GitHub-க்கு 127.0.0.1:3050 மற்றும் Slack-க்கு 127.0.0.1:3040 ஆகிய port-களில் ஏதேனும் இயங்குகிறதா என்பதை உறுதிப்படுத்தவும். பின்னர், bindings மற்றும் executors-ஐச் சரிபார்க்க opentag doctor கட்டளையை இயக்கவும்.