मुख्य सामग्रीवर जा

ज्ञात आश्चर्ये

या फाइलमध्ये रिपॉझिटरीशी संबंधित असे गोंधळाचे मुद्दे नोंदवले जातात, ज्यांमुळे एजंटकडून चुका झाल्या.

नोंदीचे निकष​

खालील सर्व गोष्टी खऱ्या असतील तरच नोंद जोडा:

  • तो मुद्दा याच रिपॉझिटरीशी संबंधित आहे (सर्वसाधारण सल्ला नाही).
  • भविष्यातील एजंटांसाठी तो पुन्हा उद्भवण्याची शक्यता आहे.
  • त्यावर प्रत्यक्ष पाळता येईल असा ठोस उपाय आहे.

शंका असल्यास, नोंद जोडण्यापूर्वी डेव्हलपरला विचारा.

नोंदीचा साचा​

### [Short title]

- **Date:** YYYY-MM-DD
- **Observed by:** agent name or contributor
- **Context:** where/when it happened
- **What was surprising:** concrete unexpected behavior
- **Impact:** what went wrong or could go wrong
- **Mitigation:** exact step future agents should take
- **Status:** confirmed | superseded

नोंदी​

Vercel अ‍ॅपचे प्रॉडक्शन डोमेन पुन्हा Git master डिप्लॉयमेंटकडे सरकू शकतात​

  • दिनांक: 2026-04-28
  • निरीक्षक: Tommaso + Codex
  • संदर्भ: Bitsocial Web अ‍ॅप डिरेक्टरीमधील Seedit आणि 5chan अ‍ॅप मिररची पडताळणी करताना.
  • आश्चर्यकारक काय होते: Vercel वरील seedit आणि 5chan प्रोजेक्टमध्ये gitProviderOptions.createDeployments = "enabled" असे होते, त्यामुळे GitHub वरील master पुशेस प्रॉडक्शन डोमेनवर प्रमोट होत होते — प्रत्यक्षात रिपॉझिटरीच्या धोरणानुसार प्रॉडक्शन अ‍ॅप मिररने फक्त रिलीज आर्टिफॅक्ट्सच सर्व्ह करणे अपेक्षित आहे.
  • परिणाम: अ‍ॅप-डिरेक्टरीतील पडताळलेले मिरर बॅज चुकीचे ठरू शकतात, कारण ज्या GitHub रिलीज ZIP मधील index.html चा हॅश about/src/lib/apps-data.ts मध्ये नोंदवलेला आहे तो न देता प्रॉडक्शन डोमेन सर्वात अलीकडचा डेव्हलपमेंट कमिट सर्व्ह करतात.
  • उपाय: मिरर पडताळणीचा मेटाडेटा जोडण्यापूर्वी किंवा तो ताजा करण्यापूर्वी, vercel api /v9/projects/<project-id> ने Vercel प्रोजेक्ट तपासा आणि gitProviderOptions.createDeployments = "disabled" असल्याची खात्री करा. रिलीज ZIP मधील मजकूर vercel deploy --prebuilt --prod ने डिप्लॉय करा आणि डेव्हलपमेंट डिप्लॉयमेंटसाठी seedit-omega.vercel.app किंवा 5chan-omega.vercel.app वापरा.
  • स्थिती: निश्चित

लाँचर HTTPS सक्तीचे करत नाही तोपर्यंत Portless 0.11 जुनीच प्रॉक्सी स्थिती वापरत राहते​

  • दिनांक: 2026-04-28
  • निरीक्षक: Tommaso + Codex
  • संदर्भ: सामान्य yarn start फ्लो जुन्या http://bitsocial.localhost:1355 या प्रॉक्सी URL वरून https://bitsocial.localhost वर नेणे.
  • आश्चर्यकारक काय होते: portless@0.11.1 इन्स्टॉल असतानाही Portless ने विद्यमान ~/.portless/proxy.port = 1355 हा HTTP प्रॉक्सी पुन्हा वापरला आणि जुनाच :1355 URL छापला.
  • परिणाम: पॅकेज आवृत्त्या आणि दस्तऐवज अद्ययावत करणे पुरेसे नाही; योगदानकर्त्याकडे जुनी Portless स्थिती चालू असल्यास yarn start अजूनही जुनाच URL दाखवू आणि वापरू शकते.
  • उपाय: स्टार्ट स्क्रिप्ट्स अ‍ॅप रूट नोंदवण्यापूर्वी पोर्ट 443 वर Portless चा HTTPS प्रॉक्सी स्पष्टपणे सुरू करतील असेच ठेवा, म्हणजे रनटाइम फ्लो साठवलेली 1355 स्थिती वारशाने घेण्याऐवजी तिच्यापासून दूर जाईल.
  • स्थिती: निश्चित

Portless कॅनॉनिकल लोकल अ‍ॅप URL बदलते​

  • दिनांक: 2026-03-18
  • निरीक्षक: Codex
  • संदर्भ: ब्राउझर पडताळणी आणि स्मोक फ्लो
  • आश्चर्यकारक काय होते: डीफॉल्ट लोकल URL हा नेहमीचा Vite पोर्ट नाही. रिपॉझिटरीला Portless मार्गे https://bitsocial.localhost अपेक्षित आहे, त्यामुळे localhost:3000 किंवा localhost:5173 तपासल्यास चुकीचे अ‍ॅप लागू शकते किंवा काहीच मिळणार नाही.
  • परिणाम: डेव्ह सर्व्हर व्यवस्थित चालू असतानाही ब्राउझर तपासण्या अयशस्वी होऊ शकतात किंवा चुकीचे लक्ष्य पडताळू शकतात.
  • उपाय: आधी हा URL वापरा: https://bitsocial.localhost. थेट Vite पोर्टची स्पष्ट गरज असेल तेव्हाच PORTLESS=0 corepack yarn start ने तो वगळा.
  • स्थिती: निश्चित

Commitizen हुक्स नॉन-इंटरॅक्टिव्ह कमिट अडवतात​

  • दिनांक: 2026-03-18
  • निरीक्षक: Codex
  • संदर्भ: एजंटद्वारे चालवले जाणारे कमिट वर्कफ्लो
  • आश्चर्यकारक काय होते: git commit केल्यावर Husky मार्गे Commitizen सुरू होते आणि ते इंटरॅक्टिव्ह TTY इनपुटची वाट पाहते, त्यामुळे नॉन-इंटरॅक्टिव्ह एजंट शेल अडकून पडतात.
  • परिणाम: जो सामान्य कमिट असायला हवा, तिथेच एजंट अनिश्चित काळ थांबून राहू शकतात.
  • उपाय: एजंटने तयार केलेल्या कमिटसाठी git commit --no-verify -m "message" वापरा. माणसे नेहमीप्रमाणे corepack yarn commit किंवा corepack yarn exec cz वापरू शकतात.
  • स्थिती: निश्चित

Yarn classic टाळण्यासाठी Corepack आवश्यक आहे​

  • दिनांक: 2026-03-19
  • निरीक्षक: Codex
  • संदर्भ: पॅकेज मॅनेजरचे Yarn 4 वर स्थलांतर
  • आश्चर्यकारक काय होते: मशीनवर PATH मध्ये अजूनही ग्लोबल Yarn classic इन्स्टॉल आहे, त्यामुळे नुसते yarn चालवल्यास पिन केलेल्या Yarn 4 ऐवजी v1 वापरले जाऊ शकते.
  • परिणाम: डेव्हलपर नकळत रिपॉझिटरीचे पॅकेज-मॅनेजर पिनिंग टाळू शकतात आणि त्यांना वेगळे इन्स्टॉल वर्तन किंवा वेगळे लॉकफाइल आउटपुट मिळू शकते.
  • उपाय: शेल कमांडसाठी corepack yarn ... वापरा, किंवा आधी corepack enable चालवा म्हणजे नुसते yarn पिन केलेल्या Yarn 4 आवृत्तीवरच जाईल.
  • स्थिती: निश्चित

ठरावीक Portless अ‍ॅप नावे Bitsocial Web वर्कट्रीजमध्ये एकमेकांशी भिडतात​

  • दिनांक: 2026-03-30
  • निरीक्षक: Codex
  • संदर्भ: एका Bitsocial Web वर्कट्रीमध्ये yarn start चालवणे, तर दुसरी वर्कट्री आधीच Portless मार्गे सर्व्ह करत असणे
  • आश्चर्यकारक काय होते: प्रत्येक वर्कट्रीमध्ये तेच bitsocial हे Portless अ‍ॅप नाव वापरल्यास मागचे पोर्ट वेगळे असूनही रूटच एकमेकांशी भिडतो, आणि bitsocial.localhost आधीच नोंदवलेले असल्याने दुसरी प्रक्रिया अयशस्वी होते.
  • परिणाम: Portless चा हेतू समांतर ब्रांच सुरक्षितपणे एकत्र नांदाव्यात असा असूनही त्या एकमेकांना अडवू शकतात.
  • उपाय: Portless ची सुरुवात scripts/start-dev.mjs मागेच ठेवा; ते आता कॅनॉनिकल प्रकरणाबाहेर ब्रांच-आधारित *.bitsocial.localhost रूट वापरते आणि नुसते bitsocial.localhost हे नाव आधीच व्यापलेले असल्यास ब्रांच-आधारित रूटवर जाते.
  • स्थिती: निश्चित

डॉक्स प्रीव्ह्यू पूर्वी पोर्ट 3001 हार्ड-कोड करत असे​

  • दिनांक: 2026-03-30
  • निरीक्षक: Codex
  • संदर्भ: इतर लोकल रिपॉझिटरी आणि एजंटांसोबतच yarn start चालवणे
  • आश्चर्यकारक काय होते: रूट डेव्ह कमांड डॉक्स वर्कस्पेस docusaurus start --port 3001 ने चालवत असे, त्यामुळे 3001 दुसऱ्या प्रक्रियेकडे असल्यास मुख्य अ‍ॅप Portless वापरत असूनही संपूर्ण डेव्ह सेशन अयशस्वी होत असे.
  • परिणाम: yarn start वेब प्रक्रिया सुरू होताच तिला बंद करू शकत असे, आणि डॉक्स-पोर्टच्या टकरावामुळे असंबंधित लोकल कामातही व्यत्यय येत असे.
  • उपाय: डॉक्सची सुरुवात yarn start:docs मागेच ठेवा; ते आता Portless सोबत scripts/start-docs.mjs वापरून दिलेला मोकळा पोर्ट स्वीकारते, किंवा थेट चालवल्यास पुढच्या उपलब्ध पोर्टवर जाते.
  • स्थिती: निश्चित

डॉक्ससाठीचे ठरावीक Portless होस्टनेम हार्ड-कोड केलेले होते​

  • दिनांक: 2026-04-03
  • निरीक्षक: Codex
  • संदर्भ: दुसऱ्या Bitsocial Web वर्कट्रीमध्ये yarn start चालवणे, तर आणखी एक वर्कट्री आधीच Portless मार्गे डॉक्स सर्व्ह करत असणे
  • आश्चर्यकारक काय होते: start:docs अजूनही तेच docs.bitsocial.localhost होस्टनेम नोंदवत असे, त्यामुळे about अ‍ॅपला स्वतःच्या होस्टनेमसाठी Portless रूट टकराव कसा टाळायचा हे माहीत असूनही yarn start अयशस्वी होऊ शकत असे.
  • परिणाम: समांतर वर्कट्री रूट डेव्ह कमांड विश्वासाने वापरू शकत नव्हत्या, कारण डॉक्स प्रक्रिया आधी बंद पडत असे आणि मग concurrently उर्वरित सेशनही बंद करत असे.
  • उपाय: डॉक्सची सुरुवात scripts/start-docs.mjs मागेच ठेवा; ते आता about अ‍ॅपसारखेच ब्रांच-आधारित Portless होस्टनेम तयार करते आणि तोच सामायिक सार्वजनिक URL /docs डेव्ह प्रॉक्सी लक्ष्यात टाकते.
  • स्थिती: निश्चित

वर्कट्री शेलमध्ये रिपॉझिटरीची पिन केलेली Node आवृत्ती वापरली न जाण्याची शक्यता असते​

  • दिनांक: 2026-04-03
  • निरीक्षक: Codex
  • संदर्भ: .claude/worktrees/* सारख्या Git वर्कट्रीमध्ये किंवा शेजारच्या वर्कट्री चेकआउटमध्ये yarn start चालवणे
  • आश्चर्यकारक काय होते: काही वर्कट्री शेलमध्ये node आणि yarn node हे Homebrew च्या Node 25.2.1 कडे जात होते, जरी रिपॉझिटरी .nvmrc मध्ये 22.12.0 पिन करते; त्यामुळे yarn start गुपचूप चुकीच्या रनटाइमवर डेव्ह लाँचर चालवू शकत असे.
  • परिणाम: मुख्य चेकआउट आणि वर्कट्री यांच्यातील डेव्ह-सर्व्हरचे वर्तन वेगळे होऊ शकते, त्यामुळे बग पुन्हा तयार करणे कठीण होते आणि रिपॉझिटरीच्या अपेक्षित Node 22 टूलचेनचे उल्लंघन होते.
  • उपाय: डेव्ह लाँचर scripts/start-dev.mjs आणि scripts/start-docs.mjs मागेच ठेवा; सध्याचे शेल चुकीच्या आवृत्तीवर असल्यास ते आता .nvmrc मधील Node बायनरीखाली स्वतःला पुन्हा चालवतात. तरीही शेल सेटअपमध्ये nvm use लाच प्राधान्य द्यावे.
  • स्थिती: निश्चित

रीफॅक्टरनंतर docs-site/ मध्ये उरलेल्या फाइल्स गहाळ डॉक्स सोर्स लपवू शकतात​

  • दिनांक: 2026-04-01
  • निरीक्षक: Codex
  • संदर्भ: Docusaurus प्रोजेक्ट docs-site/ वरून docs/ मध्ये हलवल्यानंतरची, मर्जनंतरची मोनोरेपो साफसफाई
  • आश्चर्यकारक काय होते: ट्रॅक केलेली रिपॉझिटरी docs/ वर गेल्यानंतरही जुने docs-site/ फोल्डर डिस्कवर राहू शकते, आणि त्यात i18n/ सारख्या जुन्या पण महत्त्वाच्या फाइल्स असतात. त्यामुळे रीफॅक्टर लोकल पातळीवर दुबार झाल्यासारखा दिसतो आणि ट्रॅक केलेली डॉक्स भाषांतरे प्रत्यक्षात docs/ मध्ये हलवली गेली नाहीत ही गोष्ट लपून राहते.
  • परिणाम: एजंट जुने फोल्डर “कचरा” समजून डिलीट करू शकतात आणि डॉक्स भाषांतरांची एकमेव लोकल प्रत नकळत गमावू शकतात, किंवा मृत docs-site/ पथाकडे बोट दाखवणाऱ्या स्क्रिप्ट्समध्येच बदल करत राहू शकतात.
  • उपाय: docs/ हाच एकमेव कॅनॉनिकल डॉक्स प्रोजेक्ट माना. लोकल docs-site/ मधील उरलेले काहीही डिलीट करण्यापूर्वी docs/i18n/ सारखा ट्रॅक केलेला सोर्स पूर्ववत करा आणि स्क्रिप्ट्स व हुक्समधील docs-site चे संदर्भ काढून टाका.
  • स्थिती: निश्चित

मल्टीलोकेल डॉक्स प्रीव्ह्यू पडताळणीदरम्यान RAM वापर मोठ्या प्रमाणात वाढवू शकतो​

  • दिनांक: 2026-04-01
  • निरीक्षक: Codex
  • संदर्भ: yarn start:docs आणि Playwright वापरून डॉक्स i18n, लोकेल राउटिंग आणि Pagefind वर्तन दुरुस्त करणे
  • आश्चर्यकारक काय होते: डीफॉल्ट डॉक्स प्रीव्ह्यू मोड आता सर्व्ह करण्यापूर्वी संपूर्ण मल्टीलोकेल डॉक्स बिल्ड आणि Pagefind इंडेक्सिंग करतो, आणि ती प्रक्रिया अनेक Playwright किंवा Chrome सेशनसोबत चालू ठेवल्यास सामान्य Vite किंवा एकाच लोकेलच्या Docusaurus डेव्ह लूपपेक्षा कितीतरी जास्त RAM लागते.
  • परिणाम: मशीनची मेमरी कमी पडू शकते, ब्राउझर सेशन क्रॅश होऊ शकतात, आणि मध्येच थांबलेल्या रनमुळे जुने डॉक्स सर्व्हर किंवा हेडलेस ब्राउझर मागे राहून मेमरी खात राहतात.
  • उपाय: लोकेल-रूट किंवा Pagefind पडताळणीची गरज नसलेल्या डॉक्स कामासाठी DOCS_START_MODE=live yarn start:docs ला प्राधान्य द्या. भाषांतरित रूट किंवा Pagefind तपासायचे असेल तेव्हाच डीफॉल्ट मल्टीलोकेल प्रीव्ह्यू वापरा. एका वेळी एकच Playwright सेशन ठेवा, नवीन सेशन उघडण्यापूर्वी जुनी बंद करा, आणि पडताळणीनंतर गरज नसल्यास डॉक्स सर्व्हर थांबवा.
  • स्थिती: निश्चित

translate-docs.py डॉक्स लोकेल अर्धवट भाषांतरित किंवा तुटलेल्या लिंक लक्ष्यांसह सोडू शकते​

  • दिनांक: 2026-04-06
  • निरीक्षक: Codex
  • संदर्भ: yarn start:docs ने इंग्रजी तपशील पाने सर्व्ह केल्यानंतर किंवा लोकेल आउटपुट बिल्ड करण्यात अपयश आल्यानंतर स्थानिकीकृत डॉक्स रूट आणि मजकूर दुरुस्त करणे
  • आश्चर्यकारक काय होते: डॉक्स भाषांतर पाइपलाइनमध्ये एकाच वेळी रिपॉझिटरी-विशिष्ट दोन बिघाड होते: tr(...) कॉल्स ज्या रचनांचे पार्सिंग scripts/translate-docs.py करू शकत नव्हती त्या वापरल्या असता ती DocsHome मधील मोजकेच संदेश काढत असे, आणि docs/i18n/** अंतर्गत भाषांतरित मार्कडाउनमध्ये लिंक लक्ष्यांच्या आत मशीन-भाषांतरित स्लग किंवा ZXQPLACEHOLDER अवशेष असू शकत होते.
  • परिणाम: स्थानिकीकृत मुखपृष्ठे गुपचूप इंग्रजीवर परत जाऊ शकतात, स्थानिकीकृत तपशील पाने भाषांतरित न झाल्यासारखी दिसू शकतात, आणि सोर्स डॉक्स बरोबर असूनही तुटलेल्या लोकेल लिंकमुळे संपूर्ण yarn docs:build अयशस्वी होऊ शकते.
  • उपाय: डॉक्स भाषांतरे बदलल्यानंतर किंवा लोकेल फाइल्स पुन्हा तयार केल्यानंतर, रिपॉझिटरीच्या मुळापासून नेहमी yarn docs:build चालवा, docs/i18n/** मधील मार्कडाउनमध्ये ZXQPLACEHOLDER शोधा, आणि भाषांतरित लिंक अजूनही भाषांतरित URL पथांऐवजी /apps/5chan/ सारख्या कॅनॉनिकल डॉक स्लगकडेच जातात याची खात्री करा. DocsHome चा मजकूर बदलला असल्यास, scripts/translate-docs.py अजूनही सर्व docs.home.* संदेश काढते का ते तपासा.
  • स्थिती: निश्चित

About साइटच्या no-JS तपासण्या Portless रूट वापरूनच कराव्यात, स्वतंत्र SSR प्रीव्ह्यूने नाही​

  • दिनांक: 2026-04-12
  • निरीक्षक: Codex
  • संदर्भ: ब्रांच वर्कट्रीमधून about/ साइटच्या no-JS समर्थनाची पडताळणी करणे
  • आश्चर्यकारक काय होते: स्वतंत्र SSR प्रीव्ह्यू ठीक दिसत असतानाही प्रत्यक्षातील ब्रांच-आधारित Portless रूट चुकीचे अ‍ॅप शेल किंवा जुनी प्रक्रिया सर्व्ह करत असू शकतो. या रिपॉझिटरीमध्ये खरा लोकल करार म्हणजे yarn start मधून मिळणारे Portless होस्टनेम, तात्पुरता प्रीव्ह्यू सर्व्हर नव्हे.
  • परिणाम: एजंट चुकीने no-JS समर्थन चालते असा दावा करू शकतात, किंवा फक्त *.bitsocial.localhost वरच दिसणारे रिग्रेशन चुकवू शकतात.
  • उपाय: about/ च्या ब्राउझर पडताळणीसाठी नेहमी yarn start किंवा yarn start:about ने खरा लोकल सर्व्हर सुरू करा आणि आधी ब्रांच-आधारित Portless URL तपासा. Portless होस्टनेम जुने वाटत असल्यास, पुन्हा तपासण्याआधी जुनी प्रक्रिया शोधून थांबवा.
  • स्थिती: निश्चित

chain/ हे yarn build:verify आणि yarn doctor ला दिसतच नव्हते​

  • दिनांक: 2026-07-05
  • निरीक्षक: Codex
  • संदर्भ: chain/ वर्कस्पेस (chain.bitsocial.net साठीचे स्वतंत्र Vite अ‍ॅप) मोनोरेपोमध्ये जोडल्यानंतर फक्त chain/ पुरत्या मर्यादित डिफची पडताळणी करताना.
  • आश्चर्यकारक काय होते: scripts/verify-build.mjs फक्त about/, docs/ आणि stats/ हे पथ उपसर्ग ओळखत असे, त्यामुळे रूट package.json मध्ये build:chain आधीपासून असूनही फक्त chain/ पुरता डिफ "No targeted build checks matched the current diff" एवढेच छापून एकही बिल्ड चालवत नसे. याशिवाय, yarn doctor हे react-doctor about -y वर हार्ड-कोड केलेले होते, त्यामुळे chain/src अंतर्गत React बदलांना React Doctor चे कोणतेही कव्हरेज मिळत नसे.
  • परिणाम: chain मधील बदल पडताळणाऱ्या एजंटांना yarn build:verify वर विसंबण्याऐवजी थेट yarn build:chain चालवावे लागे, आणि chain/src मधील React समस्या (इफेक्ट्स, हुक्स, निरुपयोगी कोड) yarn doctor ला सापडत नसत.
  • उपाय: scripts/verify-build.mjs मध्ये आता about/ सारखीच chain/ साठीही शाखा आहे, आणि doctor / doctor:verbose आता एकाच वेळी react-doctor --project about,chain -y चालवतात. doctor:score मात्र फक्त about पुरतेच राहते, कारण एकापेक्षा जास्त प्रोजेक्टसाठी --project सोबत वापरल्यास --score काहीही न छापता गप्प राहते; chain चा स्कोअर हवा असल्यास yarn react-doctor --project about,chain --verbose -y (किंवा --json) वापरा.
  • स्थिती: निश्चित

ब्राउझर P2P सुरक्षित WebSockets वर चालते; pkc-js डीफॉल्टनुसार WebRTC आणि WebTransport नाकारते​

  • दिनांक: 2026-08-02
  • निरीक्षक: Claude
  • संदर्भ: Bitsocial ब्राउझर P2P कसे चालते याविषयी लँडिंग पेज आणि डॉक्समधील मजकूर लिहिणे
  • आश्चर्यकारक काय होते: @pkcprotocol/pkc-js सोबत एक डीफॉल्ट कनेक्शन गेटर येतो, जो ब्राउझरमधील WebRTC आणि WebTransport डायल नाकारतो — dist/browser/helia/dial-transport-filter.js हे DENIED_DIAL_TRANSPORTS_BY_DEFAULT = ["webrtc", "webrtc-direct", "webtransport"] एक्स्पोर्ट करते. त्याच्या सोर्समधील टिप्पणीत कारण दिले आहे: ब्राउझरमध्ये हे ट्रान्सपोर्ट कनेक्शन जोडण्याचे लांब आणि अनेकदा अयशस्वी होणारे मार्ग (STUN/ICE, certhash रोटेशन) आणतात, ज्यामुळे पाने उघडायला उशीर होतो; याउलट WebSocket थेट आणि विश्वासार्ह आहे. ब्लॉगच्या P2P स्टेटस पॅनेलवरील प्रत्येक जिवंत पीअर "Secure WebSocket" दाखवतो. हा गेटर node_modules मध्ये असल्याने रिपॉझिटरीमध्ये त्याचा कोणताही सुगावा लागत नाही.
  • परिणाम: तांत्रिकदृष्ट्या पटणारा पण चुकीचा सार्वजनिक मजकूर लिहिणे अगदी सोपे आहे — उदाहरणार्थ, मार्च 2026 मध्ये WebTransport ब्राउझर Baseline पर्यंत पोहोचल्यामुळेच Bitsocial ब्राउझर P2P शक्य झाले असे श्रेय देणे. हा दावा डेव्हलपरच्या लक्षात येईपर्यंत लँडिंग पेज, तुलना तक्ता आणि दोन डॉक्स पानांवर प्रसिद्ध झाला होता. सार्वजनिक पानांवरील चुकीचे आर्किटेक्चर दावे नेमक्या त्याच डेव्हलपर वाचकवर्गाकडून तपासले जातात, ज्यांच्यासाठी ही साइट आहे.
  • उपाय: libp2p किंवा ब्राउझर प्लॅटफॉर्म तत्त्वतः कशाला पाठिंबा देते यावरून Bitsocial कोणते ट्रान्सपोर्ट वापरते हे कधीही ठरवू नका. सध्याच्या नकार-यादीसाठी node_modules/@pkcprotocol/pkc-js/dist/browser/helia/dial-transport-filter.js तपासा, about/src/ अंतर्गत कोणताही connectionGater ओव्हरराइड नाही याची खात्री करा, आणि कोणताही सार्वजनिक दावा करण्यापूर्वी ब्लॉगच्या "P2P status" पॅनेलमधील थेट ट्रान्सपोर्ट लेबल वाचा. ब्राउझरमधून पब्लिशिंग प्रत्यक्षात शक्य करणारा अपस्ट्रीम बदल म्हणजे @libp2p/gossipsub 15.0.21 (मे 2026) मधील gossipsub मोनोटोनिक-seqno दुरुस्ती; pkc-js सध्या 16.0.4 वापरते.
  • स्थिती: निश्चित

भाषांतर न झालेल्या डॉक्स पानावरील सापेक्ष ./page.md लिंक प्रत्येक स्थानिकीकृत बिल्ड तोडतात​

  • दिनांक: 2026-08-02
  • निरीक्षक: Claude
  • संदर्भ: ./peer-to-peer-protocol.md आणि ./apps/5chan.md वापरून विद्यमान डॉक्सशी जोडलेले, फक्त इंग्रजीत असलेले नवीन पान docs/browser-p2p.md जोडणे
  • आश्चर्यकारक काय होते: docs/i18n/<lang>/docusaurus-plugin-content-docs/current/ अंतर्गत प्रत्येक लोकेल हे डॉक्स ट्रीचे प्रतिबिंब असते. या प्रतिबिंबांमध्ये नसलेले नवीन पान इंग्रजी फॉलबॅकमुळे प्रत्येक लोकेलमध्ये तरीही दिसते, पण त्यातील सापेक्ष मार्कडाउन लिंक सुटत नाहीत — Docusaurus /ar/browser-p2p/peer-to-peer-protocol.md/ असे तयार करते आणि "Docusaurus found broken links!" म्हणत बिल्ड अयशस्वी करते. महत्त्वाचे म्हणजे, yarn build:verify आणि yarn docs:build:verify फक्त en बिल्ड करतात आणि व्यवस्थित पास होतात; ही चूक फक्त संपूर्ण yarn docs:build मध्येच समोर येते, आणि तो वर्णक्रमानुसार पहिल्याच लोकेलवर (ar) थांबतो.
  • परिणाम: डॉक्समधील बदल सर्व जलद लोकल तपासण्या पास होऊनही प्रॉडक्शनचा मल्टीलोकेल बिल्ड तोडू शकतो. शिवाय ही चूक बदलाशी असंबंधित वाटते, कारण एररमध्ये लेखकाने कधीही स्पर्श न केलेला लोकेल पथ दिसतो.
  • उपाय: docs/i18n/** मध्ये प्रतिबिंब नसलेल्या कोणत्याही डॉक्स पानात सापेक्ष .md लिंकऐवजी रूट-सापेक्ष लिंक (/peer-to-peer-protocol/, /apps/5chan/) वापरा; Docusaurus त्यांना आपोआप लोकेलचा उपसर्ग लावते. docs/build-your-own-client.md हे याचे विद्यमान उदाहरण आहे. डॉक्स पान जोडणारा किंवा त्याला लिंक करणारा कोणताही बदल सुपूर्द करण्यापूर्वी फक्त build:verify नव्हे, तर संपूर्ण yarn docs:build चालवा.
  • स्थिती: निश्चित

update-translations.js about/ मधूनच चालवावी लागते, आणि एकाच वेळी चालवल्यास की गुपचूप हरवतात​

  • दिनांक: 2026-08-02
  • निरीक्षक: Claude
  • संदर्भ: translate स्किलद्वारे 36 ही लोकेलमध्ये 26 भाषांतरित i18next की लागू करणे
  • आश्चर्यकारक काय होते: एकाच स्क्रिप्टमध्ये दोन वेगवेगळे सापळे. पहिला: scripts/update-translations.js आपले लक्ष्य path.join(process.cwd(), "public", "translations") असे ठरवते, पण या रिपॉझिटरीत भाषांतरे about/public/translations इथे ठेवली जातात. दस्तऐवजांत दिलेली कमांड रिपॉझिटरीच्या मुळातून चालवल्यास प्रत्येक वेळी "Translations directory not found" म्हणत ती अयशस्वी होते — docs/agent-playbooks/translations.md मध्ये node scripts/update-translations.js ... असे दाखवले आहे, जे रिपॉझिटरी-रूट कमांडसारखे वाटते. दुसरा: प्रत्येक रन 36 ही लोकेल फाइल्सवर वाचा-बदला-लिहा असे काम करते, त्यामुळे दोन रन एकाच वेळी चालल्यास ते एकमेकांवर लिहितात आणि कोणतीही एरर न देता एक की गायब होते. translate स्किल स्पष्टपणे एकाच वेळी 4 पर्यंत सबएजंट चालवण्यास सांगते, आणि त्यांतील प्रत्येक जण हीच स्क्रिप्ट चालवेल.
  • परिणाम: रिपॉझिटरी-रूटवरून चालवलेला प्रकार उघडपणे अयशस्वी होतो आणि एक संपूर्ण फेरी वाया जाते. समांतरतेची अडचण मात्र गुपचूप बिघडवते: कोणत्याही लोकेलमधून की गायब होतात, आणि तरीही डिफ बरोबर वाटतो.
  • उपाय: ती cd about && node ../scripts/update-translations.js --key <key> --map <abs-path> --write अशी चालवा. भाषांतर करणाऱ्या सबएजंटांना लोकेल फाइल्स एकाच वेळी लिहू देऊ नका — त्यांच्याकडून फक्त डिक्शनरी JSON फाइल्स तयार करून घ्या, आणि नंतर पॅरेंट एजंटकडून प्रत्येक की एकामागोमाग एक लागू करा. लागू केल्यानंतर, प्रत्येक की इंग्रजी वगळता उरलेल्या 35 ही लोकेलमध्ये आहे आणि कोणतेही मूल्य इंग्रजी सोर्सशी बाइट-टू-बाइट सारखे नाही, याची प्रोग्रामद्वारे खात्री करा.
  • स्थिती: निश्चित