CodeNomad/docs/help/ne/permissions.md
Pascal André 54a93e7c10
fix(plugins): repair damaged plugin payloads and show recovery notices once (#1239)
On a Windows Server CLI install, the console kept logging "Managed plugin
bundle differs from its digest" and the browser filled with identical
"questions and permissions not fully recovered" toasts, covering a phone's
whole screen (#1235).

The published package was correct. A bundled plugin file is named by its
sha256 in a folder shared by every connection using the same OpenCode
configuration, and it was written in place with writeFile(..., "wx"). A
concurrent installer could read it half-written, and a write interrupted
by stopping the server left a truncated file that "wx" never replaced, so
every later connection failed. Both modes were reproduced with the
published code and the exact reported error.

A payload is now published only by renaming a complete temporary copy
over its name. A file with the wrong bytes or a link is replaced the same
way; a Windows directory link is re-checked and removed with rmdir, which
never touches its target or a regular file, and a changed entry is
re-verified instead of replaced, so one installer never deletes another's
verified repair. An ordinary directory at that name is refused with a
clear error. Verification and replacement share one bounded retry with
backoff (about 3 s) for EPERM, EBUSY and EACCES locks from antivirus or
readers. Each distinct failure (error code, operation and path, with only
generated temporary names masked) is logged once as an actionable error;
repeats go to debug until provisioning succeeds.

In the UI, each recovery warning is shown at most once per project and
message per tab, across reconnects, re-added projects and reloads, and a
successful recovery re-arms it. The plugin-unavailable case is one plain
notice, "Some waiting questions may be missing", saying that requests
already waiting may not appear, new ones still do, and restarting
CodeNomad may fix it. Toasts fit narrow screens. Strings, the permissions
help page and NATIVE_INTERRUPTION_UX.md / OPENCODE_COMPATIBILITY.md are
updated in all ten locales where applicable.

Tests: installation regressions for wrong bytes, truncation, concurrent
installers, file and directory links, a reader-held lock, an ordinary
directory and a replayed concurrent-repair race; log dedupe across random
temporary names and UUID-named directories; a store test with the real
notification code (one notice after eight reconnects and a second project,
nine before). Server plugin suites, UI recovery suites, both typechecks
and the help checks pass.

Fixes #1235
2026-10-31 21:55:48 +01:00

17 KiB

प्रश्न र अनुमति

नेटिभ प्रश्न, Form र अनुमति अनुरोधको उत्तर कम्पोजरको ठीक माथिको interruption dock मा दिइन्छ, pending transcript tool card भित्र होइन।

अनुरोध खोज्नुहोस् र स्रोत जाँच्नुहोस्

  1. इनपुट आवश्यक छ / अनुमति आवश्यक छ भएको कुराकानी चयन गर्नुहोस्, वा त्यहीं dock खोल्न परियोजना अनुरोध badge क्लिक गर्नुहोस्।
  2. विस्तार वा उत्तर दिनुअघि अनुरोध प्रकार, कुराकानी शीर्षक र उत्पत्ति पढ्नुहोस्।
  3. धेरै pending अनुरोध हुँदा अघिल्लो अनुरोध / अर्को अनुरोध प्रयोग गर्नुहोस्। स्रोतमा जान चाहँदा मात्र कुराकानी हेर्नुहोस् प्रयोग गर्नुहोस्।
उत्पत्ति अर्थ र व्यवहार
खुला कुराकानी यसको अनुरोध सामान्य रूपमा विस्तार हुन सक्छ
… बाट parent सहित subagent खुला कुराकानीको पुनरावर्ती descendant स्थानीय सन्दर्भ हो; parent उत्पत्ति देखिइरहन्छ
अर्को कुराकानी संक्षिप्त पूर्वावलोकनबाट सुरु हुन्छ; हालको कुराकानी नछोडी उत्तर दिन स्पष्ट विस्तार गर्नुहोस्
परियोजना अनुरोध / सेवा अनुरोध Form को स्वामी कुराकानी नहुन सक्छ; बनावटी कुराकानी link देखाइँदैन

नयाँ आगमनले सम्पादन गर्दै गरेको अनुरोध बदल्दैन वा अन्यत्र लैजाँदैन। लाम रिफ्रेसमा चयन उही अनुरोधमा रहन्छ; तीर छेउमा पुगेर घुम्दैनन्। settlement पछि अर्को असम्बन्धित कुराकानीको अनुरोध तपाईंले नखोल्दासम्म संक्षिप्त रहन्छ।

अनुरोधहरू संक्षिप्त गर्नुहोस् ले body लुकाउँछ; केही अस्वीकार, रद्द वा उत्तर दिँदैन। विस्तारित editor ले कम्पोजरको सुरक्षित आकार वा मस्यौदा नबदली अस्थायी रूपमा न्यूनतम उचाइ बनाउँछ। यसको सामग्री स्थिर reply कार्यभन्दा स्वतन्त्र scroll हुन्छ।

प्रश्न र Form को उत्तर

  1. अभिप्रेत अनुरोध विस्तार गरी field भर्नुहोस् वा दिइएका विकल्प चयन गर्नुहोस्।
  2. विकल्प छान्ने फिल्डले आफ्नै उत्तर दिन अनुमति दिएमा थप टेक्स्ट फिल्ड देखिन्छ: दिइएको विकल्पको सट्टा त्यहाँ आफ्नै उत्तर लेख्नुहोस् (वा धेरै विकल्प छान्न मिल्ने फिल्डमा आफ्नै मानहरू थप्नुहोस्)। हरेक आवश्यक प्रश्नको उत्तर दिनुहोस्।
  3. बुझाउनुहोस् रोज्नुहोस्; त्यस्तो नेटिभ cancellation नै चाहँदा मात्र प्रश्न वा Form का लागि रद्द गर्नुहोस् प्रयोग गर्नुहोस्।

आंशिक उत्तर र अस्वीकार मस्यौदा चलिरहेको क्लाइन्टमा लाम रिफ्रेस र कुराकानी नेभिगेसनपछि पनि रहन्छन्। ती बुझाइएको निर्णय वा क्लाइन्ट डेटा खाली भएपछि पुनःप्राप्तिको प्रत्याभूति होइनन्। असफल reply सम्पादनयोग्य रहन्छ; पुनःप्रयासअघि pending अनुरोध जाँच्नुहोस्। CodeNomad ले उत्तर स्वतः दोहोर्‍याउँदैन।

केही Form ले ब्राउजर प्रक्रियाका लागि बाह्य फारम खोल्नुहोस् दिन्छन्। अनुरोधका निर्देशन पालना गरी खुलेको पृष्ठलाई सफल उत्तर नठानी यसको स्थितिमा फर्कनुहोस्। मनपरी provider/auth Form अनिवार्य रूपमा कुराकानी artifact होइनन्।

पूरा भएका नेटिभ question उपकरणले इतिहासमा प्रश्न, चयनित उत्तर, विकल्प विवरण र जस्ताको तस्तै custom पाठ देखाउँछन्। अन्य विकल्पहरू ले नछानिएका विकल्प उपलब्ध राख्छ। यी पूरा नतिजा live dock भन्दा फरक हुन्।

अनुमति स्वीकार वा अस्वीकार

  1. अनुरोधित कार्य, स्रोत र अनुरोध गरिएको डिफ पढ्नुहोस्। कुन कुराकानीले निर्णय पाउँछ जाँच्नुहोस्।
  2. चाहनुहुन्छ भने अस्वीकारको कारण वा सुरक्षित विकल्पको feedback लेख्नुहोस्।
  3. एक पटक अनुमति दिनुहोस्, सधैं अनुमति दिनुहोस् वा अस्वीकार गर्नुहोस् रोज्नुहोस्।
चयन नेटिभ असर सुरक्षा सीमा
एकपटक अनुमति यो अनुमति अनुरोध स्वीकार गर्छ असम्बन्धित भावी कार्यको एकमुष्ट स्वीकृति होइन
सधैं अनुमति लागू सत्र सन्दर्भका मिल्दा अनुरोधका लागि नेटिभ स्थायी-स्वीकृति चयन पठाउँछ CodeNomad वा OS भरको trust switch होइन; अधिकृत हुने स्रोत/pattern समीक्षा गर्नुहोस्
अस्वीकार ऐच्छिक feedback सहित अनुरोध अस्वीकार गर्छ यसअघिको काम undo गर्दैन

अनुमति स्वीकृतिले उपकरण कार्यान्वयन तुरुन्त खुलाउन सक्छ। यो dry run होइन। अनुरोधित सामग्री जाँच्न नसक्दा diff/read सीमा र स्रोत पहिचान जाँचले स्वीकृति रोक्न सक्छन्; अनुमानले फरक कार्य स्वीकृत नगरी रिफ्रेस गरेर वास्तविक अनुरोध समीक्षा गर्नुहोस्।

अर्को क्लाइन्टले settle गरे अनुरोध यहाँबाट हराउन सक्छ। timeout वा असफल reply ले नेटिभ सेवाले निर्णय स्वीकार गर्‍यो कि गरेन भन्ने प्रमाण दिँदैन: अर्को सचेत चयनअघि pending-request reconciliation लाई dock ताजा गर्न दिनुहोस्। अस्पष्ट reply कहिल्यै बनावटी पुष्टि भएको निर्णयका रूपमा देखाइँदैन।

अनुमति receipt पढ्नुहोस्

  1. नेटिभ tool card लुकेका भए पनि सम्बन्धित transcript सामग्रीछेउ अनुमति निर्णयहरू खोज्नुहोस्।
  2. स्रोत सन्देश नभएका निर्णयका लागि सत्रका अनुमति निर्णयहरू खोल्नुहोस्।
  3. जारी राख्न थप निर्णयहरू लोड गर्नुहोस्, वा read असफलपछि फेरि प्रयास गर्नुहोस् प्रयोग गर्नुहोस्।

receipt ले चिनिएका अनुरोध/स्रोत, पुष्टि भएको निर्णय र उपलब्ध कारण/उत्पत्ति अभिलेख गर्छन्। CodeNomad मा निर्णय, स्वचालित · Yolo र नेटिभ निर्णय ले देखिएका उत्पत्ति छुट्याउँछन्; नेटिभ settlement यस विन्डोमा प्रयोगकर्ताले क्लिक गरेको प्रमाण होइन।

receipt पढ्न-मात्र CodeNomad टिप्पणी हुन्, नेटिभ सन्देश वा अनुमति-नियम editor होइनन्। ती नेटिभ पूर्ण-इतिहास खोज, सन्देश प्रतिलिपि र export मा पर्दैनन्। CodeNomad offline हुँदा छुटेका निर्णय पुनर्निर्माण गर्न सक्दैनन्, र हराएको receipt को सट्टा सफल tool नतिजा राखिँदैन। सत्र मेट्दा त्यसका receipt हट्छन्।

Yolo मोड र परिवार दायरा

  1. कुराकानी चयन गरी स्थिति → Yolo मोड खोल्नुहोस्।
  2. पूरै परिवारका लागि स्वचालित अनुमति स्वीकृति स्वीकार्य हुँदा मात्र सक्षम गर्नुहोस्।
  3. थप अविश्वसनीय कामअघि अक्षम गर्नुहोस्; pending अनुरोध र पहिले नै चलिरहेका उपकरण जाँच्नुहोस्।

नियन्त्रणले सत्र भने पनि प्रभावकारी दायरा resolve भएको family root र descendants हो: child बाट सक्षम/अक्षम गर्दा त्यो परिवार प्रभावित हुन्छ। नेटिभ fork आफ्नै root मानिन्छ। यो सबै परियोजना वा स्वतन्त्र कुराकानीको global स्वीकृति होइन।

Yolo ले अनुमति मात्र स्वीकृत गर्छ। प्रश्न वा Form उत्तर दिँदैन, छुटेको जानकारी दिँदैन, सफलता सुनिश्चित गर्दैन वा ब्याकएन्ड ownership जाँच छलेर जाँदैन। स्वचालित स्वीकृति CodeNomad ब्याकएन्डले गर्छ: ब्याकएन्ड सक्रिय रहँदा एउटै विन्डो बन्द गर्नुले अक्षम गर्दैन, र रोकिएको ब्याकएन्डले स्वीकृति जारी राख्न सक्दैन। परिवार सेटिङ सुरक्षित हुन्छ र कार्यस्थान फेरि लोड हुँदा hydrate हुन्छ।

Yolo बन्द गर्दा पहिले स्वीकार गरिएको निर्णय खारेज वा फाइल/नेटवर्क असर rollback हुँदैन। स्वचालित · Yolo receipt समीक्षा गरी आवश्यक भए कार्यान्वयन स्पष्ट रोक्नुहोस्। मानव gate सहितको स्वचालनका लागि मिसन हेर्नुहोस्।

हराएका वा पुराना अनुरोध पुनःप्राप्ति

  1. जडान सूचक जाँचेर उही ब्याकएन्ड/परियोजनामा पुनःजोडिनुहोस्।
  2. recovery लाई pending नेटिभ अनुरोध मिलाउन दिनुहोस्; coverage अपूर्ण भए ज्ञात अनुरोध र मस्यौदा राखिन्छन्।
  3. प्रश्न र अनुमतिहरू पूर्ण रूपमा पुनःप्राप्त भएनन् चेतावनी देखिएमा, यसले परियोजना, कारण, फोल्डरहरू र प्रभावित सत्रहरूको नाम दिन्छ। त्यो कारण समाधान गर्नुहोस् (उदाहरणका लागि मेटिएको worktree, वा यो परियोजना बाहिर काम गरिरहेको सत्र); अर्को पुनःप्राप्ति चरणले स्वचालित रूपमा पुनः प्रयास गर्छ। प्रत्येक चेतावनी पुनः जडान र पृष्ठ पुनः लोड पछि पनि प्रति परियोजना एक पटक मात्र देखिन्छ। यसको सट्टा पर्खिरहेका केही प्रश्नहरू नदेखिन सक्छन् देखिएमा, CodeNomad ले OpenCode मा आफ्नो प्लगइनसँग सम्पर्क गर्न सकेन: नयाँ अनुरोधहरू अझै देखिन्छन्, र CodeNomad पुनः सुरु गर्दा यो समाधान हुन सक्छ; सर्भर लगले कारण बताउँछ।

recovery ले अनुरोध गन्नकै लागि हरेक निष्क्रिय worktree लोड गर्दैन। अपूर्ण जवाफ आधिकारिक खाली लाम होइन, र चेतावनी prompt, उत्तर वा स्वीकृति दोहोर्‍याउने अनुमति होइन। कन्फिगरेसन reload ले नेटिभ Form/अनुमति रद्द गर्न सक्छ; यसलाई नियमित अनुरोध-refresh बटन नबनाउनुहोस्। समस्या समाधान र OpenCode सेटअप हेर्नुहोस्।