ప్రధాన కంటెంట్‌కి దాటవేయండి

తెలిసిన ఆశ్చర్యాలు

ఏజెంట్ల తప్పులకు కారణమైన, ఈ రిపాజిటరీకి ప్రత్యేకమైన గందరగోళ అంశాలను ఈ ఫైల్ నమోదు చేస్తుంది.

ఎంట్రీ ప్రమాణాలు​

కింది అన్నీ నిజమైనప్పుడు మాత్రమే ఎంట్రీని చేర్చండి:

  • ఇది ఈ రిపాజిటరీకే ప్రత్యేకమైనది (సాధారణ సలహా కాదు).
  • భవిష్యత్తు ఏజెంట్లకు ఇది మళ్లీ ఎదురయ్యే అవకాశం ఉంది.
  • దీనికి అనుసరించదగిన నిర్దిష్ట పరిష్కారం ఉంది.

సందేహం ఉంటే, ఎంట్రీ చేర్చే ముందు డెవలపర్‌ను అడగండి.

ఎంట్రీ టెంప్లేట్​

### [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 పుష్‌లు ప్రొడక్షన్ డొమైన్‌లకు ప్రమోట్ అయ్యేవి.
  • ప్రభావం: about/src/lib/apps-data.tsలో index.html హాష్ నమోదైన GitHub రిలీజ్ ZIPకు బదులుగా ప్రొడక్షన్ డొమైన్‌లు తాజా డెవలప్‌మెంట్ కమిట్‌ను అందిస్తాయి కాబట్టి, యాప్ డైరెక్టరీలోని ధృవీకరించిన మిర్రర్ బ్యాడ్జ్‌లు తప్పుగా మారవచ్చు.
  • ఉపశమనం: మిర్రర్ ధృవీకరణ మెటాడేటాను చేర్చే ముందు లేదా తాజాకరించే ముందు, 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నే ప్రకటించి వాడగలదు.
  • ఉపశమనం: యాప్ మార్గాలను నమోదు చేయడానికి ముందే స్టార్ట్ స్క్రిప్ట్‌లు Portless HTTPS ప్రాక్సీని 443 పోర్ట్‌లో స్పష్టంగా ప్రారంభించేలా ఉంచండి; అప్పుడు రన్‌టైమ్ ఫ్లో నిల్వ ఉన్న 1355 స్థితిని వారసత్వంగా తీసుకోకుండా దాని నుండి బయటపడుతుంది.
  • స్థితి: ధృవీకరించబడింది

Portless కానానికల్ లోకల్ యాప్ URLను మారుస్తుంది​

  • తేదీ: 2026-03-18
  • పరిశీలించినవారు: Codex
  • సందర్భం: బ్రౌజర్ ధృవీకరణ, స్మోక్ ఫ్లోలు
  • ఆశ్చర్యకరమైన విషయం: డిఫాల్ట్ లోకల్ URL సాధారణ Vite పోర్ట్ కాదు. రెపో Portless ద్వారా https://bitsocial.localhost అందించాలని ఆశిస్తుంది, కాబట్టి localhost:3000 లేదా localhost:5173 తనిఖీ చేస్తే తప్పు యాప్ కనిపించవచ్చు లేదా అసలేమీ కనిపించకపోవచ్చు.
  • ప్రభావం: డెవ్ సర్వర్ ఆరోగ్యంగా ఉన్నా బ్రౌజర్ తనిఖీలు విఫలం కావచ్చు లేదా తప్పు లక్ష్యాన్ని ధృవీకరించవచ్చు.
  • ఉపశమనం: ముందుగా 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కు మార్చడం
  • ఆశ్చర్యకరమైన విషయం: యంత్రంలో ఇప్పటికీ గ్లోబల్ Yarn classic ఇన్‌స్టాల్ PATHలో ఉంది, కాబట్టి సాదా yarn నడిపితే పిన్ చేసిన Yarn 4కు బదులుగా v1 వచ్చే అవకాశం ఉంది.
  • ప్రభావం: డెవలపర్లు అనుకోకుండా రెపో ప్యాకేజీ-మేనేజర్ పిన్నింగ్‌ను దాటవేసి, వేరే ఇన్‌స్టాల్ ప్రవర్తనను లేదా వేరే లాక్‌ఫైల్ అవుట్‌పుట్‌ను పొందవచ్చు.
  • ఉపశమనం: షెల్ ఆదేశాల కోసం corepack yarn ... వాడండి, లేదా ముందుగా corepack enable నడిపి సాదా yarn పిన్ చేసిన Yarn 4కు మ్యాప్ అయ్యేలా చేయండి.
  • స్థితి: ధృవీకరించబడింది

స్థిర Portless యాప్ పేర్లు Bitsocial Web వర్క్‌ట్రీల మధ్య ఢీకొంటాయి​

  • తేదీ: 2026-03-30
  • పరిశీలించినవారు: Codex
  • సందర్భం: ఒక Bitsocial Web వర్క్‌ట్రీ ఇప్పటికే Portless ద్వారా సర్వ్ చేస్తుండగా మరో వర్క్‌ట్రీలో yarn start ప్రారంభించడం
  • ఆశ్చర్యకరమైన విషయం: ప్రతి వర్క్‌ట్రీలోనూ అక్షరాలా bitsocial అనే Portless యాప్ పేరును వాడితే, వెనుక ఉన్న పోర్ట్‌లు వేరైనా మార్గమే ఢీకొంటుంది; bitsocial.localhost అప్పటికే నమోదై ఉండటంతో రెండో ప్రాసెస్ విఫలమవుతుంది.
  • ప్రభావం: సమాంతర బ్రాంచ్‌లు సురక్షితంగా సహజీవనం చేయడమే Portless ఉద్దేశమైనా, సమాంతర Bitsocial Web బ్రాంచ్‌లు ఒకదానికొకటి అడ్డుపడతాయి.
  • ఉపశమనం: Portless ప్రారంభాన్ని scripts/start-dev.mjs వెనుకే ఉంచండి; ఇది కానానికల్ కేసు బయట బ్రాంచ్-ఆధారిత *.bitsocial.localhost మార్గాన్ని వాడుతుంది, అలాగే సాదా bitsocial.localhost పేరు అప్పటికే ఆక్రమితమై ఉంటే బ్రాంచ్-ఆధారిత మార్గానికి మారుతుంది.
  • స్థితి: ధృవీకరించబడింది

డాక్స్ ప్రివ్యూ గతంలో పోర్ట్ 3001ను హార్డ్-కోడ్ చేసేది​

  • తేదీ: 2026-03-30
  • పరిశీలించినవారు: Codex
  • సందర్భం: ఇతర లోకల్ రెపోలు, ఏజెంట్లతో పాటు yarn start నడపడం
  • ఆశ్చర్యకరమైన విషయం: రూట్ డెవ్ ఆదేశం డాక్స్ వర్క్‌స్పేస్‌ను docusaurus start --port 3001తో నడిపేది, కాబట్టి ప్రధాన యాప్ అప్పటికే Portlessను వాడుతున్నా, మరో ప్రాసెస్ 3001ను ఆక్రమించి ఉంటే మొత్తం డెవ్ సెషన్ విఫలమయ్యేది.
  • ప్రభావం: బూట్ అయిన వెంటనే yarn start వెబ్ ప్రాసెస్‌ను చంపేసేది, డాక్స్ పోర్ట్ ఘర్షణ కారణంగా సంబంధం లేని లోకల్ పనికి కూడా అంతరాయం కలిగేది.
  • ఉపశమనం: డాక్స్ ప్రారంభాన్ని yarn start:docs వెనుకే ఉంచండి; ఇది ఇప్పుడు Portlessతో పాటు scripts/start-docs.mjsను వాడి, ఇచ్చిన ఖాళీ పోర్ట్‌ను గౌరవిస్తుంది లేదా నేరుగా నడిపినప్పుడు తర్వాత అందుబాటులో ఉన్న పోర్ట్‌కు మారుతుంది.
  • స్థితి: ధృవీకరించబడింది

డాక్స్ Portless హోస్ట్‌నేమ్ స్థిరంగా హార్డ్-కోడ్ చేయబడి ఉండేది​

  • తేదీ: 2026-04-03
  • పరిశీలించినవారు: Codex
  • సందర్భం: ఒక వర్క్‌ట్రీ ఇప్పటికే Portless ద్వారా డాక్స్ సర్వ్ చేస్తుండగా, రెండో Bitsocial Web వర్క్‌ట్రీలో yarn start నడపడం
  • ఆశ్చర్యకరమైన విషయం: 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 నడపడం
  • ఆశ్చర్యకరమైన విషయం: రెపో .nvmrcలో 22.12.0ను పిన్ చేసినా, కొన్ని వర్క్‌ట్రీ షెల్‌లు node మరియు yarn nodeను Homebrew Node 25.2.1కు మ్యాప్ చేసేవి; దీంతో 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 తనిఖీలు స్వతంత్ర SSR ప్రివ్యూను కాక Portless మార్గాన్నే వాడాలి​

  • తేదీ: 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 హోస్ట్‌నేమ్ పాతదిగా అనిపిస్తే, మళ్లీ పరీక్షించే ముందు పాత ప్రాసెస్‌ను పరిశీలించి ఆపేయండి.
  • స్థితి: ధృవీకరించబడింది

yarn build:verify మరియు yarn doctorకు chain/ కనిపించేది కాదు​

  • తేదీ: 2026-07-05
  • పరిశీలించినవారు: Codex
  • సందర్భం: chain.bitsocial.net కోసం స్వతంత్ర Vite యాప్ అయిన chain/ వర్క్‌స్పేస్‌ను మోనోరెపోలో చేర్చిన తర్వాత, 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 నడుపుతాయి. ఒకటికి మించిన ప్రాజెక్ట్‌లతో --project కలిపినప్పుడు --score నిశ్శబ్దంగా ఏమీ ప్రింట్ చేయదు కాబట్టి doctor:score aboutకే పరిమితంగా ఉంది; 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 నైపుణ్యం ద్వారా 26 అనువదించిన i18next కీలను మొత్తం 36 లొకేల్‌లకు వర్తింపజేయడం
  • ఆశ్చర్యకరమైన విషయం: ఒకే స్క్రిప్ట్‌లో రెండు వేర్వేరు ఉచ్చులు. మొదటిది, 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 లొకేల్‌లన్నిటిలో ఉందని, ఏ విలువా ఇంగ్లీష్ సోర్స్‌తో బైట్-సమానంగా లేదని ప్రోగ్రామాటిక్‌గా ధృవీకరించండి.
  • స్థితి: ధృవీకరించబడింది