कोड की जगह Korean specification commit कर रहा हूं — specification की 3 शीट से PWA ऐप+सर्वर

 (github.com/SoliEstre)
1 पॉइंट द्वारा soliestre 7 시간 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें

AI से coding करवाते समय एक बात बार-बार अटकती थी। नतीजे में code तो बच जाता है, लेकिन उस code को बनाने वाली बातचीत और इरादा गायब हो जाते हैं। तीन महीने बाद “यह code ऐसा क्यों है?” पूछने की कोई जगह नहीं रहती।

इसलिए मैंने दिशा उलट कर देखी। इरादे वाली specification को git में commit करना, और code को build artifact मानना। validation के तौर पर एक छोटा app शुरू से अंत तक बनाकर public कर दिया।

यह Rimlog नाम का PWA है, जिसमें पढ़ाई/learning records में AI पुराने notes को जोड़कर आगे बढ़ा देता है। कोई server नहीं, signup नहीं, data सिर्फ browser में रहता है।

App साधारण है। मैं जो share करना चाहता हूं, वह इसे बनाने का तरीका है।

तरीका

Repo के eux/ folder में Korean में 3 specification documents हैं। पूरे app skeleton की 40 lines, AI card widget की 25 lines, insight server की एक sheet। ये इस तरह के sentences से बने हैं।

saveCapture : capture form(source name·quote·my thoughts·tags) save — captures के सबसे आगे insert + local storage reflect + “Saved” toast + records tab पर switch.

इस file को EstreUX नाम के tool में डालें तो code निकलता है (इसे brew कहते हैं)। generated code में specification का hash embed होता है, और अगर सिर्फ specification बदलें या सिर्फ code बदलें तो pre-commit में commit block हो जाता है। Specification के outdated होते ही वह झूठ बन जाने वाली समस्या को gate से रोकता है।

Numbers भी measure किए। Framework में पहले से मौजूद 152-line numeric keypad को 28-line specification में वापस बदलने जैसे actual measurements में, human-maintained lines की संख्या 60~82% घटी। Generated code खुद original से लंबा भी हो सकता है। जो घटता है, वह वह हिस्सा है जिसे इंसान पढ़ते और edit करते हैं। Measurement record repo में है।

Server भी specification की एक sheet है

Pages demo serverless है, इसलिए AI सिर्फ tag-overlap fallback से चलता है। ठीक से चलाने के लिए self-host server जोड़ा, और यह भी specification की एक sheet से brew किया गया dependency-0 वाला node single file है। Backend चुनकर इस्तेमाल करता है।

  • nvidia (default): build.nvidia.com की free API है। Card registration के बिना key देता है, OpenAI-compatible है और करीब 40 requests/minute मिलते हैं, इसलिए personal journal के लिए पर्याप्त है
  • claude-cli / codex-cli: हर request पर claude -p / codex exec को child process के रूप में call करता है। पहले से paid Claude/ChatGPT subscription को API key के बिना reuse करने का path है
  • openai / google: बस key proxy

Keys और auth सिर्फ server पर रहते हैं और browser तक नहीं जाते।

जिन बातों पर अभी भरोसा नहीं है

Specification↔code consistency judgement को static diff के अलावा property-based dynamic tests तक expand कर रहा हूं, लेकिन weight calibration अभी बाकी है। और headless DOM environment में framework render real browser से अलग चलने वाली false-positive class मिली है, इसलिए validation environment को real browser तक upgrade करना भी homework है। अगर commit history शुरू से देखें, तो scaffold→specification→generation→polishing की प्रक्रिया क्रम से बची हुई है।

दो चीजें जानना चाहता हूं। Specification को SSoT रखने के तरीके में आपको कौन-से traps दिखते हैं? खासकर specification की expressiveness code के साथ नहीं चल पाती, ऐसे point आपको कहां मिले हैं? और claude -p को app backend की तरह इस्तेमाल करने वाला subscription reuse path, real use में rate/terms/latency के लिहाज से क्या अटक सकता है?

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.