गलत सक्रिय होने से बचने वाले कीबोर्ड approval shortcuts

कीबोर्ड से दिया जाने वाला approval control authorization boundary का हिस्सा है। इसे केवल security label वाली सुविधा न समझें। अगर टर्मिनल की कोई सामान्य keystroke फ़ोकस बदलने, नया modal खुलने या repeated input की कतार के बीच से निकलकर agent call को मंज़ूरी दे सकती है, तो control ने कोई decision दर्ज नहीं किया। उसने केवल timing दर्ज की।

यह गलती production में आसानी से पहुंच जाती है, क्योंकि happy path बहुत अच्छा लगता है। Developer कोई action शुरू करता है, approval window दिखाई देती है, Return उसे स्वीकार कर देता है और सभी इसे तेज़ interaction कहते हैं। फिर वही developer terminal output पढ़ रहा होता है, windows बदलते समय कोई modifier दबाकर रखता है या किसी असंबंधित prompt को बंद करने के लिए Return दबाता है। Approval गलत समय पर पहुंचती है और action को ऐसी consent मिल जाती है जो किसी ने होशपूर्वक नहीं दी।

Approval shortcut एक security boundary है

Approval shortcut को किसी एक live action के बारे में नई और स्पष्ट रूप से किसी व्यक्ति से जुड़ी decision दिखानी चाहिए। उपयोगकर्ता के पास keyboard है या requesting process को अनुरोध करने की अनुमति है, इससे हर character approval नहीं बन जाता।

Teams अक्सर इन तीन अलग-अलग तथ्यों को एक ही मान लेते हैं:

• कोई process action का अनुरोध कर सकता है।
• मशीन के सामने कोई व्यक्ति मौजूद हो सकता है।
• वह व्यक्ति अभी इसी action को मंज़ूरी दे सकता है।

पहला तथ्य process identity से जुड़ा है। दूसरा local presence से। तीसरा authorization है। Signed process पहले तथ्य को अच्छी तरह साबित कर सकता है। दिखाई देने वाली window दूसरे का संकेत दे सकती है। इनमें से कोई भी तीसरे तथ्य को साबित नहीं करता।

Approval UI को एक छोटी state machine मानें, जिसमें approved state तक पहुंचने का रास्ता बहुत सीमित हो। उसे पता होना चाहिए कि वह कौन-सा request दिखा रहा है, इस समय input उसी के नियंत्रण में है या नहीं, keyboard activation कब eligible हुई और request अभी valid है या नहीं। इनमें से कोई भी तथ्य बदलते ही approval तक पहुंचने का पुराना रास्ता अमान्य कर दें।

एक आम implementation error shortcut को broad command handler पर लगा देता है और केवल यह जांचता है कि approval window मौजूद है या नहीं। Demo में यह harmless लगता है। इस्तेमाल के दौरान इसका मतलब होता है कि देर से पहुंचा event किसी दूसरे request, replacement के बाद पुराने request या background से अभी लौटी window को मंज़ूरी दे सकता है। व्यक्ति ने key दबाई उस क्षण button दिखाई दे रहा था या नहीं, इससे बात साबित नहीं होती।

समाधान सभी shortcuts हटाना नहीं है। Keyboard का अच्छा उपयोग करने वाले लोगों के लिए mouse-only confirmation असुविधाजनक है और उन्हें जल्दी में pointer clicks करने पर मजबूर करता है। समाधान यह है कि keyboard activation को button label से अधिक कड़ी शर्तें पूरी करनी पड़ें। System इसे तभी स्वीकार करे जब current dialog, current request, current focus generation और current physical press एक-दूसरे से मेल खाएं।

यह अंतर code review का तरीका बदल देता है। «क्या Return button पर click करता है?» पूछने के बजाय पूछें, «कौन-सा exact event इस boundary को पार कर सकता है?» अच्छे जवाब में event source, window state, request identifier और rejection cases होने चाहिए। «Dialog खुला है» कोई जवाब नहीं है।

फ़ोकस को मानकर नहीं, साबित करके चलें

Dialog का फ़ोकस जाते ही keyboard eligibility खत्म हो जानी चाहिए, भले ही एक क्षण बाद फ़ोकस फिर लौट आए। Focus transitions में एक application surface के लिए भेजा गया input दूसरे surface पर interpret हो सकता है।

एक सामान्य sequence देखें। Agent terminal में command चला रहा है। User command लिखता है, documentation पर switch करता है और तभी modal authorization window दिखाई देती है। User के हाथ अभी चल ही रहे होते हैं कि operating system active window बदल देता है। Event ordering और app framework के आधार पर Return press modal के फ़ोकस लेने के बाद पहुंच सकती है, भले ही user ने इरादा उसे देखने से पहले बनाया हो।

असुरक्षित rule आसान है: अगर authorization button default button है और window frontmost है, तो Return स्वीकार करें। यह rule frontmost status को इस बात का प्रमाण मानता है कि व्यक्ति ने request देखी और उसका मूल्यांकन किया। असल में यह केवल इतना साबित करता है कि dispatch के समय window stack में सबसे आगे थी।

इसके बजाय focus generation का उपयोग करें। Dialog सक्रिय होते ही counter बढ़ाएं और keyboard activation को disarmed करें। Current generation के लिए app ने फ़ोकस settled देख लिया हो और user की ओर से नया press भी देख लिया हो, तभी qualifying press स्वीकार करना शुरू करें। Deactivation पर armed state तुरंत साफ़ कर दें। फ़ोकस लौटने पर इसे अपने-आप restore न करें।

यह जान-बूझकर conservative व्यवहार है। जो user कहीं और switch करके वापस आता है, उसे लौटने के बाद shortcut एक बार फिर दबाना होगा। यह अतिरिक्त press मामूली है। गलती से credential वाला HTTP call या SSH command भेजना मामूली नहीं है।

यही नियम तब भी लागू होता है जब system कोई दूसरा modal sheet, password prompt, accessibility overlay, notification interaction या workspace switch दिखाता है। आपका app नहीं जान सकता कि फ़ोकस क्यों बदला और उसे अनुमान भी नहीं लगाना चाहिए। वह इतना जान सकता है कि उसकी पिछली धारणाएं अब लागू नहीं रहीं।

केवल visual focus rings पर निर्भर न रहें। वे user को बताते हैं कि input कहां जाने वाला है, लेकिन approval decision के लिए ऐसा state transition चाहिए जो app की वास्तविक active window और dialog की current generation जांचे। Visual state और authorization state एक ही source of truth से साथ-साथ बदलने चाहिए।

एक उपयोगी manual test यह है: approval dialog खोलें, modifier दबाकर रखें, कहीं और switch करें, वापस आएं और तुरंत Return दबाएं। इसे dialog के बाहर pointer click, system alert और fast application switch के साथ दोहराएं। हर प्रयास में request तब तक pending रहना चाहिए जब तक कोई नया explicit action न हो। अगर एक भी variation approval दे, तो keyboard path बहुत broad है।

दबाकर रखे गए input के लिए अलग state machine चाहिए

Dialog के keyboard के लिए eligible होने से पहले जो key दबाई जा चुकी थी, वह dialog को authorize नहीं कर सकती। यह नियम उन bugs पर लागू होता है जिनमें कोई व्यक्ति Return, Space, Escape या modifier दबाकर रखता है और UI उसके नीचे बदल जाता है।

Event APIs अक्सर down, repeat और up phases देती हैं, लेकिन application code इन्हें घटाकर «received Return» कर देता है। इससे वही जानकारी खो जाती है जो महत्वपूर्ण है। Terminal में शुरू हुए press का अर्थ उस press से अलग है जो approval request दिखाई देने और फ़ोकस में आने के बाद शुरू होती है।

हर accepted shortcut के लिए physical lifecycle track करें। Dialog shortcut तभी स्वीकार करे जब वह अपनी activation epoch के बाद non-repeat down event देखे, उस समय फ़ोकस उसके पास हो और उसके बाद platform के completion rule के अनुसार प्रक्रिया पूरी हो। अगर dialog खुलते समय event पहले से down है, तो उस key के लिए up event तक blocker लगा दें। Repeat से fresh press का अनुमान न लगाएं।

Space को भी Return जितनी सावधानी चाहिए। कई controls keyboard activation के लिए Space का उपयोग करते हैं और लोग preview, scrolling या accessibility actions के लिए Space दबाकर रखते हैं। Escape की भी जांच करें। उसे केवल स्क्रीन पर मौजूद live request cancel करना चाहिए और user के दबाने के बाद दिखाई देने वाले replacement request को cancel नहीं करना चाहिए।

Modifier combinations के लिए और सख्त policy चाहिए। Bare modifier state को permission न मानें और Control-C, Control-D या Control-R जैसी terminal habits से टकराने वाले shortcuts से बचें। अगर आप कोई chord चुनते हैं, तो dialog के arm होने के बाद ही पूरा chord शुरू होना चाहिए। अगर किसी member के दबे रहते फ़ोकस बदल जाए, तो उसे reject करें। किसी दूसरी window में शुरू हुआ chord आपके dialog के बारे में decision नहीं है।

एक छोटा internal record पर्याप्त है:

requestId: 84f2
focusGeneration: 17
armedAfterEvent: 912
returnIsBlockedUntilUp: true
approvalState: pending

नाम मायने नहीं रखते। नियम मायने रखता है: event dialog की current focus generation से नया होना चाहिए और fresh input lifecycle का हिस्सा होना चाहिए। Teams अक्सर accidental approval की report मिलने के बाद यह state जोड़ती हैं। Shortcut जोड़ने से पहले ही इसे शामिल करें।

Modal timing सामान्य input को authorization में बदल देती है

गलत क्षण पर दिखाई देने वाला modal उस input को प्राप्त कर सकता है जिसे व्यक्ति underlying task के लिए इस्तेमाल कर रहा था। खतरा event timing से आता है, dialog के polished confirmation message से नहीं।

Timing की कई gaps को नाम देना उपयोगी है। Key down और key up के बीच request आ सकता है। Application state request identifier जोड़ने से पहले UI render हो सकता है। Previous request बंद हो सकता है, जबकि queued callback अभी भी उसका completion handler पकड़े हो। New dialog वही button object दोबारा इस्तेमाल कर सकता है और पुराना keyboard action नए content की ओर इशारा कर सकता है।

आम failure कुछ ऐसा दिखता है:

1. User terminal में command submit करने के लिए Return दबाता है।
2. Press जारी रहते agent process permission मांगता है।
3. App approval dialog दिखाता है और उसका default button active कर देता है।
4. Key up या repeated event नए responder तक पहुंचता है।
5. App उस event को approval मानकर action भेज देता है।

User शायद dialog पढ़ भी न पाए। फिर भी application audit entry में लिखती है कि user ने approval दिया था, जिससे failure और गंभीर हो जाती है। Record code path के बारे में सही है, लेकिन human act के बारे में गलत।

इसे activation barrier से रोकें। Presentation के समय event subsystem से monotonic input sequence या timestamp record करें और उन events को reject करें जो barrier से पहले शुरू हुए थे। अगर platform reliable sequence नहीं देता, तो dialog के visibly active होने के बाद पूरा fresh press अनिवार्य करें। Platform ambiguity छोड़ता हो तो conservative design चुनें।

Input generations के साथ request generations भी इस्तेमाल करें। हर button action और keyboard handler को immutable request token से बांधें। Dialog बंद होने पर उस token को revoke करें। कोई दूसरा request उसकी जगह ले तो पुराने object को mutate करने के बजाय नया token बनाएं। पुराना token लेकर आया callback denial लौटाए, भले ही नया dialog दिखाई दे रहा हो।

Timing की समस्या केवल «300 milliseconds तक Return ignore करें» जैसे delay से हल करने की कोशिश न करें। Delays लोकप्रिय हैं क्योंकि उन्हें समझाना और code करना आसान है। Slow machines, तेज़ focus changes, accessibility input और वैध रूप से अधिक समय लेने वाले लोगों के मामले में वे विफल होते हैं। Delay समय मापता है। आपको input event और current dialog state के बीच संबंध मापना है।

Terminal की muscle memory hostile input है

Terminal का काम ठीक वही keystrokes पैदा करता है जिन पर approval dialog को भरोसा नहीं करना चाहिए। Developers command submit करने के लिए Return, काम रोकने के लिए Control-C, output में आगे बढ़ने के लिए Space और edit छोड़ने के लिए Escape दबाते हैं। Agents terminal activity को और लगातार बनाते हैं, इसलिए authorization window आदतन किए जा रहे input की stream के बगल में दिखाई दे सकती है।

यह न मानें कि terminal किसी अलग application boundary के पीछे है। लोग embedded terminals, split panes, remote shells, full-screen windows और ऐसे tool panes इस्तेमाल करते हैं जो terminals जैसे दिखते हैं। कोई process output में developer को key दबाने के लिए कहने के तुरंत बाद भी authorization request शुरू कर सकता है। Visual story user की motor plan से तेज़ी से बदल सकती है।

सुरक्षित default यह है कि approval dialog कोई inherited input consume न करे। फ़ोकस और arming के बाद मिलने वाली fresh Return press स्वीकार की जा सकती है, लेकिन shell command submit करने वाली Return, paging के लिए दबाकर रखी गई Space और किसी भी key से पैदा हुए repeat को reject करना होगा। अगर UI यह अंतर साबित नहीं कर सकती, तो shortcut हटा दें और pointer या biometric confirmation अनिवार्य करें।

Global command map में terminal-जैसे commands से dangerous approval को bind न करें। Global listener modal की local responder chain से बाहर के events भी देखता है और यह साबित करना कठिन बना देता है कि activation कहां से शुरू हुई। Handler को specific live dialog से जोड़े रखें, फिर dialog से अपना request token verify करवाएं और उसके बाद ही authorization layer से action करने को कहें।

यहीं copy और paste पर भी ध्यान देना चाहिए। Pasted newline terminal में सामान्य text हो सकती है और form control में activation। Approval controls को text insertion और ऐसे command dispatch को ignore करना चाहिए जिसमें qualifying physical shortcut event न हो। Pasted character data है, consent नहीं।

सिर्फ synthetic window पर नहीं, वास्तविक terminal workflow के साथ test करें। ऐसा command शुरू करें जो बार-बार prompt दे, Return दबाते समय request trigger करें और Control-C तथा Space इस्तेमाल करने के बाद test करें। Terminal के फ़ोकस में होने पर, documentation window के फ़ोकस में होने पर और window switch के दौरान authorization window दिखाई देने पर भी test करें। उद्देश्य उस intent को दोहराना है जो कहीं और शुरू हुआ था।

Painted button नहीं, event history test करें

सबसे उपयोगी tests hostile event history को reducer में भेजते हैं और assert करते हैं कि exact सही sequence आने तक वह approval emit न करे। Snapshot tests यह पुष्टि कर सकते हैं कि dialog focused दिखता है। वे यह नहीं बता सकते कि stale event ने boundary पार की या नहीं।

Dialog को present, focusGained, focusLost, keyDown, keyRepeat, keyUp, requestRevoked और approveClick जैसे explicit events के साथ model करें। हर event को request token और monotonically बढ़ते input sequence के साथ दें। Reducer को तीन में से एक outcome देना चाहिए: pending रहना, cancel करना या matching token के लिए approval emit करना।

यह fixture interaction code के पास रखने लायक छोटा है:

[
  {"seq": 41, "type": "keyDown", "key": "Return"},
  {"seq": 42, "type": "present", "request": "r-19"},
  {"seq": 43, "type": "focusGained", "request": "r-19"},
  {"seq": 44, "type": "keyUp", "key": "Return"},
  {"seq": 45, "type": "keyDown", "key": "Return"},
  {"seq": 46, "type": "keyUp", "key": "Return"}
]

Expected output shape भी उतनी ही महत्वपूर्ण है:

[
  {"seq": 44, "decision": "pending", "reason": "inherited-input"},
  {"seq": 46, "decision": "approved", "request": "r-19"}
]

अगर आपका implementation sequence 44 पर approval दे देता है, तो उसने dialog के मौजूद होने से पहले शुरू हुई press स्वीकार कर ली है। यही bug है, जिसे screenshot या हफ्ते में एक बार होने वाली race के बिना दिखाया जा सकता है।

Labels के बजाय state changes के आधार पर एक compact test matrix बनाएं। कम-से-कम इन cases को शामिल करें:

• Presentation से पहले shortcut दबा हो और focus आने के बाद छोड़ा जाए।
• Fresh press शुरू होने के बाद फ़ोकस चला जाए और release से पहले वापस आ जाए।
• Request pending रहते repeat event आए।
• Request A बंद हो, request B खुले और पुराना handler चले।
• Dialog दिखाई देने के बाद vault या कोई दूसरी prerequisite state बदले।

हर case में assert करें कि कोई action न भेजा जाए और audit trail design के अनुसार denial या no decision दर्ज करे। किसी event को चुपचाप ignore करना ठीक हो सकता है। Reducer ने denial दिया हो, लेकिन record approval का दावा करे, यह स्वीकार्य नहीं है।

फिर UI integration test करें, क्योंकि कई अच्छे reducers को bypass यहीं किया जाता है। Verify करें कि हर activation route एक ही gate से होकर जाए: pointer click, Return, Space, accessibility action, programmatic default-button action और कोई भी menu command। जो अलग shortcut path सीधे action call करता है, वह समय के साथ button path से अलग हो जाएगा।

इन tests में action executor के लिए dependency injection इस्तेमाल करें। Test को call object तभी मिलना चाहिए जब reducer current token के लिए approval emit कर चुका हो। Calls गिनें, request token capture करें और पुराना token executor तक पहुंचे तो test fail करें। इसे वास्तविक HTTP request या SSH command भेजकर test न करें। Authorization boundary credential या network के बिना test की जा सकती है।

Manual testing फिर भी ज़रूरी है, क्योंकि operating systems focus और accessibility events ऐसे paths से भेजते हैं जिन्हें mocks miss कर सकते हैं। Plain language में छोटा regression script लिखें, उसे oldest supported system और current system पर चलाएं और physical keyboard से पूरा करें। Fast window switching, held keys, repeated keys, system alerts, screen lock, sleep से wake और visible रहते request revoke होने की स्थिति शामिल करें। Script में हर action के बाद अपेक्षित decision लिखा होना चाहिए, केवल यह नहीं कि dialog ने सही व्यवहार किया।

अस्वीकार किया गया event अस्वीकार ही रहना चाहिए

एक बार event approval predicate में विफल हो जाए, तो बाद के UI changes उसे valid नहीं बना सकते। यह बात तब स्पष्ट नहीं रहती जब implementation generic «pending approve» flag रखता है और फ़ोकस लौटने या animation खत्म होने के बाद उसे फिर जांचता है।

Event की rejection को terminal बनाएं। अगर Return disarmed स्थिति में आए, तो उसे inherited input के रूप में record करें या discard कर दें, फिर बाद की fresh press का इंतज़ार करें। Chord के दौरान फ़ोकस बदले तो उस chord को invalidate करें। Request बदले तो previous request से जुड़े हर event और callback को invalidate करें। Conditions बेहतर होने की स्थिति में code को candidate approval बचाकर नहीं रखना चाहिए।

यह principle duplicate actions से भी बचाता है। Double click, keyboard action के बाद pointer action या event replay से दो external calls नहीं होने चाहिए। Authorization layer एक approval token स्वीकार करते ही action dispatch करने से पहले request को consumed mark करे। उस token के बाद की activations harmless duplicate rejection दें।

UI outcome और external action outcome को अलग रखें। UI «approved for dispatch» तभी कहे जब उसने decision state बंद कर दी हो। इसके बाद executor स्वतंत्र रूप से सफल या विफल हो सकता है। Network request विफल हो जाए तो पुराने approval token को फिर सक्रिय न करें और अगली keystroke पर चुपचाप retry न करें। अगर user को एक और प्रयास authorize करना है, तो फिर से पूछें, खासकर तब जब action payload या destination बदल सकती हो।

यहीं audit design उपयोगी साबित होती है। इतना context log करें कि यह समझा जा सके कि input stale, repeated, unfocused, revoked या पहले ही consumed होने के कारण reject हुआ। हर keystroke का capture बनाकर log को surveillance record न बनाएं। आपको decision का evidence चाहिए, निगरानी का रिकॉर्ड नहीं।

Identity, authorization और scope के अलग-अलग जवाब चाहिए

भरोसेमंद approval flow यह स्पष्ट करता है कि अनुरोध किसने किया, वह क्या करना चाहता है और क्या human ने उसी specific action को मंज़ूरी दी है। एक जवाब को दूसरे के स्थान पर इस्तेमाल नहीं करना चाहिए।

Process identity उपयोगी है, क्योंकि इससे human तय कर सकता है कि requester अपेक्षित है या नहीं। macOS पर code-signing authority बदल सकने वाले process name से अधिक meaningful signal दे सकती है। फिर भी अपेक्षित process unexpected request कर सकता है और stray shortcut से human गलत request को मंज़ूरी दे सकता है।

Scope अलग बात है। Low-risk काम के लिए session permission उचित हो सकती है, अगर human ने उसे जांच लिया हो, लेकिन इससे हर future call वही decision नहीं बन जाती। Per-action confirmation का उद्देश्य अलग है: जब action credential का उपयोग करे या sensitive destination तक पहुंचे, तब यह fresh judgement मांगती है। Interaction इस तरह design करें कि user देख सके कि वह कौन-सी layer बदल रहा है।

External effect वाले request के लिए «Allow» जैसे अस्पष्ट labels से बचें। Method, destination और meaningful operation को ऐसी भाषा में बताएं जिसे operator जांच सके। Dialog को dense packet dump भी न बनाएं। पहले decision-relevant facts दिखाएं और exact details को बिना scrolling exercise के approval पर निर्भर किए उपलब्ध रखें।

Sallyport इन layers को जान-बूझकर सीमित रखता है: locked vault हर action को deny करता है, नया agent process डिफ़ॉल्ट रूप से session authorization मांगता है और चुने गए credentials हर उपयोग पर fresh approval मांग सकते हैं। यह design अपने-आप keyboard interaction को सुरक्षित नहीं बनाता। Shortcut को अब भी साबित करना होगा कि current person ने current call को approve किया है।

Failure trace उबाऊ लगे, तभी ship करें

Shortcut तभी release करें जब hostile input से सामान्य और आसानी से समझ आने वाली denials मिलें। व्यक्ति presentation के दौरान Return दबाकर रख सके, chord के बीच window बदल सके, repeated Space trigger कर सके या replacement request के साथ race कर सके, फिर भी external call न हो।

UI change के साथ उसी review में test fixture भी रखें। Reviewer से event sequence पढ़वाएं, जो साबित करे कि stale key boundary पार नहीं कर सकती। Implementation में एक ही authorization function expose होना चाहिए, जो request identity, focus generation, input freshness और consumption state की जांच करे। Convenience handlers उसी function को call करें, उसे bypass न करें।

Production logs में ऐसे patterns देखें जो friction का संकेत देते हों, लेकिन predicate को कमजोर न करें। Modal दिखने के बाद inherited-input denials बहुत हों तो request awkward समय पर आ रही हो सकती है। Request कब और कैसे दिखाई जाती है, उसे बेहतर करें या pointer और biometric route दें। System ने जिन events को सही रूप से reject किया है, उन्हें स्वीकार करके metric को «ठीक» न करें।

व्यक्ति के request देखने के बाद अच्छा approval shortcut बिल्कुल साधारण महसूस होता है। Optimize करने लायक यही speed है। बाकी हर fast path terminal की muscle memory को authorization में बदलने का एक और तरीका है।