macOS पर agent approval में हर build को अलग पहचानना ज़रूरी है

किसी AI agent को केवल उसके परिचित command name से approve करना गलत executable को approve करने जैसा है। एक ही Mac पर vendor release, beta, package-manager copy और source से बनाया गया build जमा होना आसान है, और सबका command name एक ही हो सकता है। अगर आपकी approval boundary इन copies को अलग नहीं पहचान सकती, तो reviewed build के लिए लिया गया निर्णय चुपचाप किसी दूसरी copy पर भी लागू हो सकता है।

इसका हल लंबी allowlist नहीं है। आपको तय करना होगा कि आपके environment में agent run की पहचान किन properties से होती है, हर installed copy में उन properties की जाँच करनी होगी और फिर दोनों copies मौजूद रहते हुए approval behavior को test करना होगा। Paths, signatures, designated requirements और hashes अलग-अलग सवालों के जवाब देते हैं। इन्हें आपस में मिला देना ही सबसे बड़ी समस्या बनता है।

एक command name कई executables की ओर इशारा कर सकता है

Shell command lookup होता है, identity नहीं। जब आप claude, agent या किसी wrapper का नाम लिखते हैं, तो shell alias, function, shim, symlink, package-manager directory या PATH में पहले आने वाली file चुन सकता है। हो सकता है यह वह copy न हो जिसे आप ध्यान में रखकर approval दे रहे थे।

उस terminal, editor, launch service या automation runner से शुरुआत करें जो वास्तव में agent शुरू करता है। किसी सुविधाजनक interactive shell की जाँच करके यह न मान लें कि वही परिणाम हर जगह लागू होगा। Login shells, GUI applications और CI runners को अक्सर अलग environment variables मिलते हैं।

पहले यह चलाएँ:

type -a agent-name
command -v agent-name

उपयोगी परिणाम कुछ ऐसा दिख सकता है:

agent-name is /Users/me/bin/agent-name
agent-name is /opt/homebrew/bin/agent-name
agent-name is /usr/local/bin/agent-name
/Users/me/bin/agent-name

इस output का मतलब है कि इस shell में पहला path चुना जाएगा। इससे यह पता नहीं चलता कि /Users/me/bin/agent-name direct binary है, symlink है, ऐसा script है जो किसी दूसरी binary को शुरू करता है, या ऐसा wrapper है जो control आगे देने से पहले environment variables बदलता है।

जाँच से पहले file को resolve करें:

BIN="$(command -v agent-name)"
python3 - <<'PY' "$BIN"
import os, sys
print(os.path.realpath(sys.argv[1]))
PY
file "$BIN"

अगर file shell script दिखाए, तो उसे पढ़ें। अगर symlink दिखाए, तो उसके destination की जाँच करें। अगर universal Mach-O executable दिखाए, तो उसी executable की जाँच करें। Wrapper approval screen पर सब कुछ सही दिखा सकता है, लेकिन बाद में कोई अलग child process शुरू कर सकता है।

सिर्फ मौजूदा winner मिलने पर न रुकें। type -a के हर परिणाम के साथ vendor के Applications folder, Downloads folder, source checkout और package-manager cellars में मौजूद copies की भी inventory बनाएँ। Package-manager upgrade या छोटे PATH बदलाव के बाद आज जीतने वाला path कल हार सकता है।

Path location का सबूत है, identity का प्रमाण नहीं

Teams अक्सर path rule से शुरुआत करती हैं क्योंकि paths पढ़ना आसान होता है। /Applications/Agent.app जानबूझकर चुना हुआ लगता है। /Users/me/dev/agent/bin/agent प्रयोगात्मक लगता है। ये उपयोगी संकेत हैं, लेकिन केवल path यह साबित नहीं कर सकता कि उस जगह अभी कौन-सा code मौजूद है।

Package manager किसी स्थिर symlink के पीछे की file बदल सकता है। Direct installer app bundle को उसी जगह overwrite कर सकता है। Local build हर बार वही output path इस्तेमाल कर सकता है। पर्याप्त write access वाला attacker approved path पर file बदल सकता है। Path केवल यह बताता है कि loader ने file कहाँ से ढूँढी।

अपनी inventory में चार अलग fields रखें:

यह अंतर महत्वपूर्ण है क्योंकि हर field अलग गति से बदलता है। Vendor update path और designated requirement को बनाए रखते हुए hash बदल सकता है। Beta signing authority वही रख सकता है, लेकिन अलग bundle identifier इस्तेमाल कर सकता है। Local build में release जैसा source revision हो सकता है, फिर भी उस पर ad hoc signature या कोई signature न हो।

Apple का Technical Note TN2206 designated requirement की भूमिका समझाता है। इसका उद्देश्य किसी program के legitimate updates से match करना और असंबंधित code को बाहर रखना है। इसलिए यह continuity mechanism है। इसका मतलब यह नहीं कि यह इस सवाल का सार्वभौमिक जवाब है, «क्या मेरा मतलब इसी exact binary से था?» Apple यह भी बताता है कि default requirement signing setup से तैयार होती है, इसलिए developer ने build को जिस तरह sign किया है, उसके आधार पर इसकी चौड़ाई बदलती है।

Approval systems में भी यही अलगाव चाहिए। Publisher के अगले compatible release पर भरोसा करने का निर्णय, किसी एक exact release artifact पर भरोसा करने के निर्णय से अलग है। दोनों को एक ही decision मानने पर यह समझाना असंभव हो जाता है कि user ने वास्तव में किस चीज़ को approve किया।

Approval rule बनाने से पहले signature की जाँच करें

हर candidate executable के लिए signature details और hash रिकॉर्ड करें। नीचे दिए commands में केवल macOS के built-in tools और shasum का इस्तेमाल होता है:

inspect_agent() {
  target="$1"
  echo "=== $target ==="
  echo "Resolved path: $(python3 - <<'PY' "$target"
import os, sys
print(os.path.realpath(sys.argv[1]))
PY
)"
  shasum -a 256 "$target"
  codesign --display --verbose=4 "$target" 2>&1 \
    | grep -E '^(Executable|Identifier|TeamIdentifier|Authority|CDHash)='
  codesign --display -r- "$target" 2>&1 \
    | sed -n '/designated/,$p'
  codesign --verify --strict --verbose=2 "$target" 2>&1
}

inspect_agent "$(command -v agent-name)"

Output का ढाँचा किसी खास vendor string से अधिक महत्वपूर्ण है:

=== /opt/homebrew/bin/agent-name ===
Resolved path: /opt/homebrew/Cellar/agent-name/2.4.1/bin/agent-name
3b1f...  /opt/homebrew/bin/agent-name
Executable=/opt/homebrew/bin/agent-name
Identifier=com.example.agent
TeamIdentifier=AB12CDE345
Authority=Developer ID Application: Example, Inc. (AB12CDE345)
CDHash=9c1a...
designated => anchor apple generic and identifier "com.example.agent" and certificate leaf[subject.OU] = "AB12CDE345"
/opt/homebrew/bin/agent-name: valid on disk
/opt/homebrew/bin/agent-name: satisfies its Designated Requirement

दिखाए गए CDHash को अपने SHA-256 record का विकल्प न मानें। CodeDirectory hash code-signing machinery का हिस्सा है और signature structure के साथ बदल सकता है। shasum -a 256 test record के लिए exact file का परिचित fingerprint देता है। Collision की जाँच करते समय दोनों रिकॉर्ड करें।

App bundle के लिए केवल bundle directory की नहीं, actual executable की जाँच करें। इसे इस तरह ढूँढें:

APP="/Applications/Agent.app"
EXEC="$APP/Contents/MacOS/$(defaults read "$APP/Contents/Info" CFBundleExecutable)"
inspect_agent "$EXEC"

अगर agent कोई helper शुरू करता है, तो helper की भी जाँच करें। Terminal window खोलने वाला executable हमेशा HTTP calls करने या SSH शुरू करने वाली process नहीं होता। Approval system को उस process की पहचान करनी चाहिए जो sensitive action का अनुरोध करती है, जबकि test में पूरी launch chain की जाँच होनी चाहिए।

Apple का नया TN3127 पुराने signing guide से आगे जाता है। इसमें बताया गया है कि अलग-अलग signing types में default designated requirements कैसे बदलती हैं और अलग वितरित variants एक-दूसरे के साथ compatible क्यों नहीं हो सकते। यह धारणाओं से बचने की चेतावनी है। अपनी installed files से मिले actual requirement text की तुलना करें।

Stable, beta, package-manager और local builds के लिए test matrix चाहिए

Inventory को ठोस बनाएँ। अपने Mac पर संभवतः मौजूद copies चुनें, हर एक को छोटा label दें और रिकॉर्ड करें कि उनसे दूसरों के साथ क्या समान होने की उम्मीद है और क्या अलग होना चाहिए।

यह table सही उत्तर तय नहीं करती। यह उस लापरवाह उत्तर से बचाती है जिसमें channel name को पर्याप्त मान लिया जाता है। Beta को stable की तरह ही sign किया जा सकता है। Package-manager copy बिना बदला vendor artifact, repackaged artifact या ऐसा script हो सकती है जो कोई दूसरी executable download करता है। Local build पर valid development signature हो सकती है, जो उसे वास्तविकता से अधिक official दिखाए।

अपने agent setup notes के साथ रखी text file में हर installed copy के लिए एक row बनाएँ:

label: stable
launch path: /Applications/Agent.app/Contents/MacOS/agent-name
resolved path: /Applications/Agent.app/Contents/MacOS/agent-name
version: 2.4.1
identifier: com.example.agent
team or authority: AB12CDE345
sha256: 3b1f...
designated requirement: anchor apple generic and identifier "com.example.agent" ...
expected approval group: release

label: local
launch path: ~/src/agent/build/agent-name
resolved path: /Users/me/src/agent/build/agent-name
version: git revision recorded separately
identifier: ad hoc or absent
team or authority: none
sha256: 8e52...
designated requirement: unavailable or different
expected approval group: local only

Version रिकॉर्ड करें, लेकिन decision को version number पर निर्भर न होने दें। Version strings application metadata हैं। कोई file ऐसा version string बता सकती है जो आपके डाउनलोड किए गए release से मेल न खाता हो। Signature और hash स्वतंत्र facts देते हैं।

असुविधाजनक स्थिति तब होती है जब दो rows में identifier, team और designated requirement समान हों, लेकिन hashes अलग हों। यह ज़रूरी नहीं कि कोई defect हो। इसका मतलब है कि publisher ने दो builds बनाए हैं जिन्हें macOS एक ही program के instances मान सकता है। अगर आप चाहते हैं कि approval publisher के release channel के साथ आगे बढ़े, तो यह स्वीकार्य हो सकता है। अगर approval केवल किसी खास release artifact तक सीमित होना चाहिए, तो यह बहुत व्यापक है।

गलत test हर copy को अलग-अलग approve करता है

सोमवार को stable build और मंगलवार को beta build test करने से cross-coverage के बारे में लगभग कुछ पता नहीं चलता। हर test में prompt आ सकता है, क्योंकि उस समय कोई active approval मौजूद नहीं होता। दोनों copies installed रखें और एक copy की session चलती रहे, तभी दूसरी access माँगे।

यह sequence disposable account में या ऐसे credentials के साथ चलाएँ जो production systems को बदल न सकें:

1. Stable, beta, package-manager और local copies रखें। उनके resolved paths की पुष्टि करें और inspection output सुरक्षित रखें।
2. आपके approval tool के जरिए मौजूदा agent session clear या revoke करें। पुष्टि करें कि अगली sensitive call पर नया decision माँगा जाएगा।
3. Stable copy शुरू करें और test endpoint पर harmless call करें। केवल इस run को approve करें। इसकी process को चलता हुआ रखें।
4. Stable process चलती रहते beta copy शुरू करें और वही harmless call करें। देखें कि क्या approval माँगा जाता है और card पर दिखाई गई process identity की जाँच करें।
5. Package-manager और local copies के साथ दोहराएँ। फिर PATH order बदलकर package-manager test दोबारा करें।

आपको मिलने वाला परिणाम चुने गए rule पर निर्भर है। अगर stable और beta अलग होने चाहिए, तो stable approved रहते beta को prompt दिखना चाहिए। अगर वे जानबूझकर एक approval group साझा करते हैं, तो card और audit trail में इतना विवरण होना चाहिए कि reviewer के लिए यह grouping स्पष्ट हो।

इस test में production API न चलाएँ। ऐसे test endpoint का इस्तेमाल करें जो fixed response लौटाए और अपने logs में दिखाई देने वाला harmless marker छोड़े। SSH के लिए ऐसी test account इस्तेमाल करें जिसका command केवल identity information print करने तक सीमित हो:

ssh [email protected] 'id; hostname; date -u +%FT%TZ'

Test में दो observations हैं: approval screen क्या कहती है और target system के logs में क्या दर्ज होता है। Timestamp, executable hash, process ID और returned marker सुरक्षित रखें। अगर wrapper ने वास्तव में चलने वाली executable बदल दी, तो यह अंतर post-incident discussion से पहले ही दिखाई देगा।

एक सामान्य failure ऐसा दिखता है। Developer stable app approve करता है, फिर beta install करता है। Shell setup में /Users/me/bin को /Applications से पहले रखा जाता है। Command name वही रहता है। Beta बिना नए prompt के call कर लेता है, क्योंकि authorization check shared signing identity या बहुत व्यापक process grouping को पहचानता है। किसी को पता नहीं चलता, क्योंकि original stable process अभी भी चल रही है और audit record में केवल agent-name लिखा है। इस failure को रोकने का तरीका overlap test करना है, release notes पढ़ना नहीं।

Process identity और exact bytes अलग approval questions के जवाब देते हैं

Approval ऐसी signed process identity से जुड़ सकता है जो updates के बीच stable रहती है। वह exact bytes से भी जुड़ सकता है। इनमें से कोई विकल्प हर स्थिति में सही नहीं है।

Process identity तब इस्तेमाल करें जब आपका उद्देश्य किसी known signer की maintained release line पर भरोसा करना हो। इससे केवल executable hash बदलने पर user को हर patch release approve नहीं करना पड़ता। सामान्य update path में fixed process identity भरोसा बनाए रख सकती है।

Exact bytes तब इस्तेमाल करें जब build experimental हो, local बनाया गया हो, independently patched हो या ऐसे channel से आया हो जिसे आप stable के साथ मिलाना नहीं चाहते। Short investigation या reproduction के लिए hash pin खास तौर पर उपयोगी है, क्योंकि file बदलते ही approval समाप्त हो सकती है।

खतरनाक बीच का रास्ता यह मानना है कि केवल signing identifier ही identity है। Apple के अनुसार एक signing identifier का दावा कई signers कर सकते हैं। Code की जाँच करते समय Apple इसे relevant validation और team constraints के साथ जोड़ने की सलाह देता है। व्यावहारिक रूप से Identifier=com.example.agent बिना authority या team के केवल ऐसा label है जिसे कोई और भी इस्तेमाल कर सकता है।

Designated requirement आम तौर पर अधिक मजबूत होती है, क्योंकि यह identifier को signing authority constraints के साथ जोड़ सकती है। फिर भी यह आपके इरादे से व्यापक हो सकती है। एक team द्वारा एक identifier के तहत signed किसी भी valid build को स्वीकार करने वाली requirement stable update, beta और vendor-generated local test build को सही ढंग से एक साथ रख सकती है। यह तभी अच्छा है जब आप सचमुच तीनों को एक approval group में रखना चाहते हों।

Inventory entry के साथ group decision को सरल भाषा में लिखें। उदाहरण के लिए:

Release group: accept future vendor-signed builds with the release identifier.
Beta group: separate, even when signed by the same vendor identity.
Local group: exact SHA-256 only; rebuild requires another approval.

यह note UI में click करने से पहले decision लेने के लिए मजबूर करती है। इससे यह भी पता चलता है कि आपका tooling यह अंतर व्यक्त कर सकता है या नहीं। अगर नहीं कर सकता, तो कोई संकीर्ण operational boundary इस्तेमाल करें, जैसे beta और local builds के लिए per-call approval, जब तक tooling ऐसा करने योग्य न हो।

Per-session approval, per-call approval का विकल्प नहीं है

Per-session approval इस सवाल का जवाब देती है, «क्या यह agent process इस run के दौरान access के साथ चल सकती है?» Per-call approval पूछती है, «क्या यह specific credential अभी इस specific action के लिए इस्तेमाल हो सकती है?» पहला control तय करता है कि कौन-सी process session पा सकती है। दूसरा उस session के प्रभाव को सीमित करता है।

Sallyport एक fixed decision ladder इस्तेमाल करता है: locked vault हर action को deny करता है, नए agent process को आम तौर पर session approval चाहिए होती है और चुने गए credentials हर इस्तेमाल पर fresh approval माँग सकते हैं। Approval card process की code-signing authority को सबसे पहले दिखाता है, जो उपयोगी evidence है, लेकिन जब एक से अधिक builds मौजूद हों तो overlap test फिर भी करें।

ऐसे credentials के लिए अधिक बार जाँच रखें जो irreversible या externally visible बदलाव कर सकते हैं। Production deployment credentials, destructive administrative APIs और shared infrastructure बदल सकने वाली SSH access को केवल इसलिए trust नहीं मिलना चाहिए कि लंबी run की शुरुआत में agent process स्वीकार्य थी।

Binary collision का हल यह नहीं कि हर credential पर हमेशा हर-call approval लगा दें। इससे design problem approval fatigue में बदल जाती है। लोग बार-बार आने वाले predictable prompts को पढ़े बिना approve करने लगते हैं। इसके बजाय उन builds को अलग करें जिन्हें access साझा नहीं करना चाहिए, फिर उन actions के लिए per-call approval रखें जहाँ human को इस्तेमाल का क्षण देखना ज़रूरी है।

Action gateway के लिए action boundary पर यही matrix test करें। हर binary शुरू करें, अगर दोनों channels इस्तेमाल होते हैं तो एक test HTTP request और एक test SSH command चलाएँ, फिर session record और individual-call record की तुलना करें। Records से यह पता चलना चाहिए कि request किस executable ने शुरू की, कौन-सा approval उस पर लागू हुआ और credential को दूसरी confirmation चाहिए थी या नहीं।

Package managers और shims उस executable को छिपा सकते हैं जिसकी जाँच करनी है

Package managers अक्सर ऐसे stable front-door paths install करते हैं जो कहीं और point करते हैं। /opt/homebrew/bin/agent-name पर मौजूद command versioned Cellar directory के भीतर symlink हो सकती है। कोई दूसरा tool JavaScript, Python या shell shim install कर सकता है, जो runtime चुनकर cache directory से package load करता है।

Chain को तब तक follow करें जब तक उस process तक न पहुँच जाएँ जो sensitive request करती है। सामान्य मामलों में ये commands मदद करती हैं:

ls -l "$(command -v agent-name)"
readlink "$(command -v agent-name)" || true
head -n 40 "$(command -v agent-name)" 2>/dev/null || true

macOS पर readlink केवल एक hop दिखा सकता है। पहले section वाला छोटा Python resolver final target के लिए अधिक भरोसेमंद है। अगर front-door file script है, तो exec, runtime invocations, downloaded binary paths और release channel चुनने वाले environment variables खोजें।

यह न मानें कि package-manager version उसी number वाले vendor version के बराबर है। Package patches लगा सकता है, binary को repackage कर सकता है, source से compile कर सकता है या अलग runtime शुरू कर सकता है। Approval उस installed executable को दें, और package receipt को केवल supporting context की तरह रखें।

यही चेतावनी IDE extensions और terminal integrations पर भी लागू होती है। Graphical launcher एक copy bundle कर सकता है, जबकि shell दूसरी इस्तेमाल करता है। हर ऐसे entry point को test करें जो agent शुरू कर सकता है। «Terminal में सही prompt आता है» यह editor से शुरू हुए background task के बारे में कोई प्रमाण नहीं है।

Local builds को साफ़ तौर पर local होना चाहिए

Local build उपयोगी इसलिए है क्योंकि वह release से अलग हो सकता है। उसमें कोई patch, unreviewed dependency update, compiler change, debug flag या generated file हो सकती है जो vendor artifact में कभी शामिल नहीं हुई। उसे चुपचाप release build की approval reputation नहीं मिलनी चाहिए।

पहले उसकी signing state की जाँच करें:

LOCAL="$HOME/src/agent/build/agent-name"
codesign --display --verbose=4 "$LOCAL" 2>&1 | sed -n '1,25p'
codesign --verify --strict --verbose=2 "$LOCAL" 2>&1
shasum -a 256 "$LOCAL"

Unsigned output, ad hoc signature और development signature एक-दूसरे के विकल्प नहीं हैं। Unsigned executable approval layer को कम टिकाऊ identity evidence देती है। Ad hoc signature file को signed दिखा सकती है, लेकिन उसे developer identity से नहीं जोड़ती। Development signature development context की पहचान करती है, फिर भी file को release artifact नहीं बनाती।

सबसे सुरक्षित default सरल है: local binaries को अलग directory में रखें, अगर build पर आपका नियंत्रण है तो उन्हें visibly अलग command name दें और hash बदलने पर नई approval माँगें। अगर command rename नहीं कर सकते, तो runbook और test output में resolved path और local-build status स्पष्ट रखें।

हर local build को release में इस्तेमाल certificate से केवल prompts कम करने के लिए re-sign करने की लोकप्रिय सलाह से बचें। यह लोकप्रिय इसलिए है क्योंकि development आसान हो जाता है। लेकिन अगर आपका approval model signing authority को meaningful boundary मानता है, तो यह गलत है। इससे release identity उन सभी machines और scripts तक फैल जाती है जिनके पास उस certificate की access है। Casual local builds में release signing material न रखें, जब तक release process उस दावे को बनाए रखने में सक्षम न हो।

Audit records से बाद में पूरा decision समझ आना चाहिए

«agent approved» लिखने वाला approval record कमजोर evidence है। छह हफ्ते बाद आप नहीं बता पाएँगे कि approved program stable installer, beta folder, package-manager symlink या local checkout से आया था।

हर test और meaningful operational change के लिए ये facts सुरक्षित रखें:

• launching path और final resolved path
• signing identifier, authority या team और designated requirement text
• SHA-256 hash और application version
• process ID, start time और session outcome
• action target और individual-call outcome

Sallyport agent runs को Sessions journal में और individual actions को Activity journal में रखता है। दोनों encrypted hash-chained audit log से तैयार होते हैं। इसका offline sp audit verify check यह बता सकता है कि encrypted log chain अभी भी verify होती है या नहीं, लेकिन log integrity उन identity fields को पूरा नहीं कर सकती जिन्हें आपने रिकॉर्ड ही नहीं किया। Machine की जाँच संभव रहते executable evidence को event context का हिस्सा बनाएँ।

Build matrix बदलने, session revoke करने और overlap test दोहराने के बाद audit verification चलाएँ। आपको दो बातें सुनिश्चित करनी हैं: system ने आपकी अपेक्षा के अनुसार अलग-अलग runs रिकॉर्ड किए और record trail अलग से पढ़ने पर भी verify होती है। Clean chain record की continuity साबित करती है, आपकी मूल grouping decision की समझदारी नहीं।

इसे one-time cleanup नहीं, regression test बनाएँ

Multiple copies वापस आती रहती हैं। कोई fix test करने के लिए beta install करता है। Package manager रातोंरात upgrade हो जाता है। Teammate local build साझा करता है। Stable app in-place update होती है। अगर आप केवल किसी incident के बाद test करेंगे, तो collision उस समय पता चलेगी जब agent को access पहले ही मिल चुकी होगी।

एक छोटा test script रखें जो हर candidate path के लिए timestamp वाला report लिखे। Installation changes के बाद, नया high-impact credential देने से पहले और shell startup files या editor agent settings बदलने पर इसे चलाएँ।

#!/bin/zsh
set -eu

for candidate in \
  "/Applications/Agent.app/Contents/MacOS/agent-name" \
  "/opt/homebrew/bin/agent-name" \
  "$HOME/src/agent/build/agent-name"; do
  [[ -e "$candidate" ]] || continue
  echo "### $candidate"
  echo "resolved: $(python3 -c 'import os,sys; print(os.path.realpath(sys.argv[1]))' "$candidate")"
  shasum -a 256 "$candidate"
  codesign --display --verbose=4 "$candidate" 2>&1 \
    | grep -E '^(Identifier|TeamIdentifier|Authority|CDHash)=' || true
  codesign --display -r- "$candidate" 2>&1 \
    | grep 'designated' || true
  echo
 done

Report की तुलना पिछली reviewed copy से करें। Update के बाद hash बदलना अपेक्षित है। Signing authority, identifier या designated requirement बदलना routine update मानने से पहले explicit decision माँगता है। type -a में release path से पहले दिखाई देने वाला नया path भी उतनी ही जाँच चाहता है।

व्यावहारिक मानक स्पष्ट है: approval उसी executable group पर लागू होनी चाहिए जिसे आपने चुना था, और आपके evidence से पता चलना चाहिए कि उस group में एक build क्यों शामिल है और दूसरा क्यों बाहर है। Stable, beta, package-manager और local copies को एक ही Mac पर रखें, एक approved process चलती रहने दें और हर दूसरी copy को approval माँगने पर मजबूर करें। अगर परिणाम आपको चौंकाता है, तो approval boundary बहुत अस्पष्ट है।