dsh-doublecheck 0.5.0

package/README.hi.md

@@ -0,0 +1,252 @@
+# dsh-doublecheck
+
+> **शिप करने से पहले दोबारा जाँचें: आवश्यकताओं की पड़ताल करें, कार्यान्वयन का परीक्षण करें, डिलीवरी साबित करें।**
+
+[![version](https://img.shields.io/badge/version-0.5.0-blue)](https://github.com/PerryLink/dsh-doublecheck/releases)
+[![license](https://img.shields.io/badge/license-Apache--2.0-blue)](LICENSE)
+[![topics](https://img.shields.io/badge/topics-dsh%20%7C%20dsh--plugin-22c55e)](https://github.com/topics/dsh-plugin)
+
+[DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) के लिए एक **इंजीनियरिंग-अनुशासन बंडल**। एजेंट तुरंत कोड लिखना चाहते हैं; आवश्यकताएँ मान लिए जाना पसंद नहीं करतीं। `dsh-doublecheck` एक अनुशासन-चक्र स्थापित करता है जो एजेंट को **पहले संपादन से पहले आवश्यकताओं की पड़ताल करने** और **डिलीवरी का दावा करने के बजाय उसे साबित करने** के लिए बाध्य करता है — पूरी तरह DSH के अपने एक्सटेंशन पॉइंट्स (स्किल रजिस्ट्री, टूल पॉलिसी पाइपलाइन, अप्रूवल सीम, उप-एजेंट और वर्कफ़्लो सीम, सेशन लॉग) पर मूल रूप से पुनः लागू, किसी उधार की प्रॉम्प्ट फ़ाइल पर नहीं। DSH `0.1.0-rc.6` के विरुद्ध परीक्षण किया गया।
+
+कार्यप्रणाली [obra/superpowers](https://github.com/obra/superpowers) और [TimothyVang/Grill-me](https://github.com/TimothyVang/Grill-me) से प्रेरित है। इस पैकेज का हर प्रॉम्प्ट, शब्द, उदाहरण और फ़ाइल शुरू से लिखा गया है — दोनों में से किसी भी परियोजना से कुछ भी कॉपी नहीं किया गया।
+
+## क्यों
+
+- अस्पष्ट कार्य गलत सॉफ़्टवेयर बनाते हैं। एक छोटा सा अनुरोध («मेरे लिए एक फ़ीचर बनाओ») छह अनसुलझे निर्णय छिपाता है; आज एजेंट सभी का अनुमान लगाता है और आप उस अनुमान की कीमत चुकाते हैं।
+- अनुशासित टीमें यही इंसानों के साथ करती हैं: आवश्यकता-समीक्षा → असफल परीक्षण → सफल परीक्षण → आत्म-समीक्षा → डिलीवरी-प्रमाण। एजेंट भी उसी चक्र के हक़दार हैं — हार्नेस द्वारा लागू, भरोसे से नहीं।
+
+## अनुशासन-चक्र
+
+```
+grill ──▶ design ──▶ red ──▶ green ──▶ review ──▶ verify
+  │         │
+  │      (v0.1)        (v0.2+)        (v0.3)         (v0.4)
+  │
+  └─ आवश्यकता-भट्टी: छह आयाम, सहमति-द्वार,
+     संरचित spec सेशन और वर्कस्पेस में दर्ज
+```
+
+| चरण | अर्थ | स्थिति |
+|---|---|---|
+| **grill** | छह आवश्यकता-आयामों की पड़ताल; सहमति तक कार्यान्वयन से इनकार। | ✅ v0.1 |
+| **design** | `doublecheck_spec` से spec दर्ज। | ✅ v0.1 |
+| **red** | असफल परीक्षण अंतर साबित करता है; कार्यान्वयन संपादनों को यह लॉग में दर्ज चाहिए। | ✅ v0.2 |
+| **green** | संपादनों के बाद पास होने वाला परीक्षण चक्र पूरा करता है। | ✅ v0.2 |
+| **review** | एक फ़ॉर्क किया गया विरोधी-आलोचक spec के विरुद्ध डिलीवरी का ऑडिट करता है। | ✅ v0.3 |
+| **verify** | `doublecheck_report` + प्रति-आयाम सत्यापन वर्कफ़्लो डिलीवरी साबित करते हैं। | ✅ v0.4 |
+
+## विशेषताएँ (v0.5)
+
+- 🔥 **`grill-requirements` स्किल** — Agent Skills प्रारूप में पैक की गई स्किल, जो DSH की मूल `ask_user_question` UI से कार्य की छह आयामों (**लक्ष्य, दायरा, स्वीकृति-मानदंड, विफलता-स्थितियाँ, प्राथमिकताएँ, निषेध**) पर पड़ताल करती है, सहमति तक कोड लिखने से इनकार करती है और अनुबंध दर्ज करती है।
+- 🧰 **पूरे चक्र के लिए चरण-स्किल्स** — `red-green-tdd` (असफल परीक्षण लिखें, red चलाएँ, लागू करें, green चलाएँ), `delivery-review` (green के बाद spec के विरुद्ध प्रतिकूल आत्म-समीक्षा) और `delivery-proof` (पूर्णता घोषित करने से पहले प्रमाण को डिलीवरी रिपोर्ट में समेकित करें) `grill-requirements` से जुड़ गए: छहों चरणों में मॉडल-मार्गदर्शन है, सिर्फ़ पहले में नहीं।
+- 📜 **`doublecheck_spec` टूल** — सहमत spec को सेशन लॉग में दर्ज करता है और वर्कस्पेस में markdown प्रति लिखता है, ताकि अनुबंध बातचीत के बाद भी बचा रहे।
+- 🔄 **कार्य-बदलाव पर फिर grill** — दर्ज spec अपने ही कार्य को कवर करता है: नवीनतम spec के बाद उपयोगकर्ता का नया सीधा अनुरोध उस फ़ॉलो-अप के लिए grill द्वार फिर खोल देता है, पुराने अनुबंध को चुपचाप विरासत में लेने के बजाय।
+- 🛡️ **अनुशासन गार्ड** — टूल पॉलिसी पाइपलाइन पर एक नरम द्वार। अस्पष्ट कार्य + spec नहीं + `edit`/`write` की ओर बढ़ना → `intensity` के अनुसार **याद दिलाना**, **मानव अनुमोदन माँगना** या **रोकना**।
+- 🟥🟩 **Red/green प्रमाण-द्वार** (`modules.tdd`) — सेशन लॉग पर कड़ी जाँचें: कार्यान्वयन संपादन के लिए पिछले पास होने वाले परीक्षण के बाद से एक **असफल परीक्षण लॉग में दर्ज** होना चाहिए (परीक्षण फ़ाइलें लिखना हमेशा अनुमत है — red चरण ऐसे ही घटता है), और जो टर्न संपादनों के साथ पर बिना किसी पास होने वाले परीक्षण के समाप्त होता है, उसमें green अनुस्मारक इंजेक्ट होता है।
+- 👁️ **विरोधी-समीक्षा** (`modules.adversary`) — जब डिलीवरी green पर पहुँच जाती है, तब एक फ़ॉर्क किया गया आलोचक उप-एजेंट (DSH का मूल उप-एजेंट सीम, डिफ़ॉल्ट `fork` provider) प्रतिकूल रुख़ के साथ दर्ज spec के विरुद्ध सेशन का ऑडिट करता है और संरचित निष्कर्ष लौटाता है। `remind` आलोचना इंजेक्ट करता है; `warn`/`block` इसके अलावा एक राउंड चलाकर मॉडल से निष्कर्षों का उत्तर दिलवाते हैं। `adversaryModel` आलोचक को अलग मॉडल पर भेजता है; आलोचक की टूल allowlist डिफ़ॉल्ट रूप से read-only है। निष्कर्ष टिकाऊ `doublecheck-review` संदेश-स्रोत पर सवार होते हैं। आलोचक के निपटने के बाद समीक्षा फिर सक्रिय हो जाती है: नवीनतम समीक्षा-रिकॉर्ड के बाद कार्यान्वयन संपादन अगला राउंड चलाते हैं, और टर्न रद्द करने पर चालू आलोचक बाधित होता है।
+- 📊 **Doublecheck रिपोर्ट + सत्यापन वर्कफ़्लो** (`doublecheck_report`, v0.4) — सेशन के अनुशासन-प्रमाण (spec, red/green समयरेखा, समीक्षा-निष्कर्ष, संपादन) को एक डिलीवरी रिपोर्ट में समेकित करता है, जिसमें व्युत्पन्न निर्णय होता है (`grill → draft → red → green → objections/verified → proven/challenged/unverified`), वर्कस्पेस में लिखी जाती है। `verify` के साथ, प्रति-आयाम जाँचकर्ता DSH के वर्कफ़्लो सीम से चलते हैं (`verifyMode: all` हर आयाम के लिए एक समानांतर जाँचकर्ता लॉन्च करता है; `single` एक संयुक्त जाँचकर्ता चलाता है) और उनके निर्णय रिपोर्ट में समाहित होते हैं — `proven` के लिए हर आयाम का निर्णय ज़रूरी है।
+- 🚦 **डिलीवरी द्वार** — टर्न-सीमा पर, जो डिलीवरी बिना दर्ज `doublecheck_report` के green पर पहुँची है, उसे पूर्णता घोषित करने से पहले रिपोर्ट-अपेक्षित अनुस्मारक मिलता है; सफल रिपोर्ट चरण को `verify` पर बढ़ा देती है।
+- 🔁 **टिकाऊ स्थिति** — मॉडल को दिखने वाली हर चीज़ (spec, अनुस्मारक, अस्वीकृति-फ़ीडबैक, समीक्षा-निष्कर्ष, `/doublecheck on|off` स्विच) सेशन लॉग में दर्ज होती है; द्वारों के निर्णय केवल लॉग से निकलते हैं (`tool/call` + `tool/result`, Code Mode उप-प्रेषण सहित), इसलिए पुनः आरंभ या फ़ॉर्क की गई सेशन भी वैसा ही व्यवहार करती हैं। `remindOnce` भी टिकाऊ है: जिस सेशन को अनुस्मारक मिल चुका, उसे दोबारा कभी नहीं मिलता, रीस्टार्ट के बाद भी।
+- ⌨️ **`/doublecheck` सेशन कमांड** — `status` प्रभावी स्विच, कॉन्फ़िगर किए मॉड्यूल और folded चरण बताता है; `report` डिलीवरी रिपोर्ट वहीं fold करता है; `on|off` टिकाऊ `doublecheck/state` ओवरराइड लिखता है और स्विच-सूचना इंजेक्ट करता है।
+- 📚 **`doublecheck_skills` टूल** — आधिकारिक स्किल-रजिस्ट्री सीम से पैकेज की स्किल्स सूचीबद्ध व लोड करता है।
+
+## डेमो
+
+`intensity: block` और सभी द्वार सक्षम के साथ एक वास्तविक headless रन, टिकाऊ सेशन लॉग से दर्ज की गई ट्रांसक्रिप्ट:
+
+```sh
+dsh --profile demo headless "把这个项目里最慢的代码直接改快，别问我任何问题，直接改文件。"
+```
+
+1. **grill** पहले संपादन को रोकता है — कोई spec दर्ज नहीं:
+   `Error: Blocked by the dsh-doublecheck requirements guard: the task statement is vague and no doublecheck_spec exists for this session.`
+2. मॉडल spec (`doublecheck_spec`) दर्ज करता है, एक असफल परीक्षण लिखता है (परीक्षण फ़ाइलें हमेशा संपादन-योग्य होती हैं) और उसे चलाता है — लॉग `[exit code: 1]` दर्ज करता है, red चरण।
+3. कार्यान्वयन संपादन अब पास होते हैं; बाद का रन `4 passed` दर्ज करता है, green चरण।
+4. फ़ॉर्क किया गया आलोचक डिलीवरी का ऑडिट करता है; उसके गंभीरता-टैग वाले निष्कर्ष इंजेक्ट होते हैं, और `warn`/`block` एक राउंड चलाते हैं ताकि मॉडल उनका उत्तर दे।
+5. `doublecheck_report` सब कुछ एक markdown रिपोर्ट में समाहित कर देता है, जिसमें व्युत्पन्न निर्णय होता है — `proven` जब हर प्रति-आयाम सत्यापन जाँच पास होती है, `challenged` जब कोई जाँचकर्ता आपत्ति करता है।
+
+## स्थापना
+
+```sh
+dsh plugin --profile <name> add dsh-doublecheck
+dsh --profile <name> --dump-config   # "# == dsh-doublecheck" परत दिखनी चाहिए
+```
+
+दोनों प्लगइन पंक्तियाँ profile के साथ अपने आप सक्रिय होती हैं। tarball से भी:
+
+```sh
+pnpm pack
+dsh plugin --profile <name> add ./dsh-doublecheck-0.5.0.tgz
+```
+
+git से स्थापना के लिए npm की ज़रूरत नहीं:
+
+```sh
+dsh plugin --profile <name> add "github:PerryLink/dsh-doublecheck#v0.5.0"
+```
+
+## अनइंस्टॉल
+
+```sh
+dsh plugin --profile <name> remove dsh-doublecheck
+```
+
+पैकेज रखकर सिर्फ़ एक पंक्ति बंद करने के लिए: profile के `cordis.patch.yml` में उस पंक्ति को id से ओवरराइड कर `disabled: true` करें (`doublecheck-grill` / `doublecheck-guard`)।
+
+## संगतता
+
+- `0.1.0-rc.6` peers (`@deepseek-ai/cordis ^4.0.1`) के विरुद्ध सत्यापित; अंतिम सत्यापन 2026-08-14 (Windows + Node 22)।
+- टिकाऊ सत्र स्विच (`/doublecheck on|off` → `doublecheck/state`) को host की `ignorable` लेखन-सतह चाहिए (rc.6 के बाद का harness): rc.6 hosts options bag अनदेखा कर देते हैं और इवेंट required-on-read रहता है, इसलिए harness अपग्रेड होने तक इन-मेमोरी स्विच बेहतर है।
+
+## अनुमतियाँ और डेटा
+
+- **पढ़ता है**: केवल प्रक्रिया के भीतर सत्र लॉग (`tool/call` / `tool/result` / `tool/code-dispatch` और इंजेक्टेड `user/message` स्रोत)।
+- **लिखता है**: सत्र workspace में `doublecheck-spec.md` व `doublecheck-report.md` (पथ configurable), `ctx.fs` seam से।
+- **मॉडल कॉल**: केवल वैकल्पिक एडवर्सरी समीक्षा (`modules.adversary`, डिफ़ॉल्ट off) और `doublecheck_report` का सत्यापन वर्कफ़्लो (डिफ़ॉल्ट on) subagent चलाते हैं; इसके अलावा न मॉडल कॉल, न नेटवर्क।
+- **कभी नहीं छूता**: क्रेडेंशियल, एनवायरनमेंट वेरिएबल या सत्र workspace से बाहर की कोई फ़ाइल।
+
+## समस्या निवारण
+
+| लक्षण | कारण और समाधान |
+|---|---|
+| `--dump-config` में `# == dsh-doublecheck` परत नहीं | bundle patch ग़ायब है या कोई पंक्ति `disabled` है — profile का patch क्रम और पंक्ति ids जाँचें। |
+| gates कभी प्रतिक्रिया नहीं देते | `/doublecheck status` चलाएँ: सत्र स्विच बंद हो सकता है, या guard पंक्ति के सारे `modules.*` false हैं। |
+| "Adversary review did not run: the subagents seam is not mounted" | इस profile संयोजन में subagent प्रदाता नहीं — एक लगाएँ (spine संयोजन लाते हैं) या `modules.adversary` बंद करें। |
+| `doublecheck_report` में `verification: null` | `workflowEngine` seam ग़ायब है या run अस्वीकृत/रुका — रिपोर्ट अनुमान लगाने के बजाय यही कहती है। |
+| रिपोर्ट कहती है `unverified` | सत्यापन चला पर हर spec आयाम का फ़ैसला नहीं मिला — `verify: true` से दोबारा चलाएँ; `proven` के लिए छहों चाहिए। |
+
+## कॉन्फ़िगरेशन
+
+profile के `cordis.patch.yml` में किसी भी पंक्ति को **id से** ओवरराइड करें। patch पंक्ति की पूरी config बदल देता है — हर कुंजी दोबारा लिखें:
+
+```yaml
+- id: doublecheck-grill
+  config:
+    specFile: 'specs/doublecheck-spec.md'   # डिफ़ॉल्ट: 'doublecheck-spec.md'
+    reportFile: 'specs/doublecheck-report.md'   # डिफ़ॉल्ट: 'doublecheck-report.md'
+    reportVerify: true            # डिफ़ॉल्ट रूप से सत्यापन वर्कफ़्लो चलाएँ
+    verifyProvider: 'fork'        # प्रति-आयाम जाँचकर्ताओं के लिए provider
+    reportTestToolNames: ['bash', 'pwsh']
+    reportTestCommandPatterns:
+      - '(?:^|[;&|]\s*)(?:(?:pnpm|npm|npx|yarn|bun)(?:\s+run)?\s+(?:test|vitest|jest|mocha)(?:\s|$))'
+      - '(?:^|[;&|]\s*)(?:(?:pytest|go\s+test|cargo\s+test|make\s+test|ctest)(?:\s|$))'
+      - '(?:^|[;&|]\s*)(?:node\s+--test(?:\s|$))'
+    reportMutationTools: ['edit', 'write']
+    reportTestFilePatterns:
+      - '(^|[\\/])(tests?|__tests__|specs?)([\\/]|$)'
+      - '\\.(test|spec)\\.[A-Za-z0-9]+$'
+
+- id: doublecheck-guard
+  config:
+    intensity: warn
+    modules:
+      grill: true
+      tdd: true         # red/green प्रमाण-द्वार (v0.2)
+      adversary: true   # फ़ॉर्क किए आलोचक की समीक्षा (v0.3)
+    adversaryModel: null
+    adversaryProvider: 'fork'       # वह उप-एजेंट provider जिस पर आलोचक चलता है
+    adversaryMaxFindings: 5         # सेशन में इंजेक्ट होने वाली निष्कर्ष-सीमा
+    adversaryTools: ['read', 'glob', 'grep']   # आलोचक की टूल allowlist (read-only)
+    adversaryTimeoutMs: 120000      # एक आलोचक रन के लिए कठोर बजट
+    guardTools: ['edit', 'write']
+    vagueTaskMaxChars: 200
+    remindOnce: true
+    testToolNames: ['bash', 'pwsh']
+    testCommandPatterns:
+      - '(?:^|[;&|]\s*)(?:(?:pnpm|npm|npx|yarn|bun)(?:\s+run)?\s+(?:test|vitest|jest|mocha)(?:\s|$))'
+      - '(?:^|[;&|]\s*)(?:(?:pytest|go\s+test|cargo\s+test|make\s+test|ctest)(?:\s|$))'
+      - '(?:^|[;&|]\s*)(?:node\s+--test(?:\s|$))'
+    testFilePatterns:
+      - '(^|[\\/])(tests?|__tests__|specs?)([\\/]|$)'
+      - '\\.(test|spec)\\.[A-Za-z0-9]+$'
+```
+
+### `intensity`
+
+| मान | द्वार-नियंत्रित `edit`/`write` पर व्यवहार |
+|---|---|
+| `remind` (डिफ़ॉल्ट) | कॉल जारी रहती है; अनुस्मारक परिणाम-संदर्भ के साथ अगले मॉडल अनुरोध में जाता है। |
+| `warn` | कॉल अप्रूवल सीम से एकबारगी मानव अनुमोदन हेतु रोकी जाती है (कोई चैनल न होने पर अस्वीकार)। |
+| `block` | कॉल अस्वीकार होती है; फ़ीडबैक मॉडल को पहले अनुशासन सुधारने की ओर भेजता है। |
+
+### ट्यूनिंग
+
+| कुंजी | डिफ़ॉल्ट | अर्थ |
+|---|---|---|
+| `modules.grill` | `true` | `false` पर grill द्वार बंद। grill स्किल/टूल का स्विच उनकी पंक्ति का `disabled` फ़्लैग है। |
+| `modules.tdd` | `false` | `true` पर red/green प्रमाण-द्वार चालू (v0.2)। |
+| `modules.adversary` | `false` | `true` पर green (v0.3) पर फ़ॉर्क किए आलोचक की समीक्षा चालू होती है; `ctx.subagents` सीम का उपयोग करती है — सीम अनुपस्थित होने पर «अनुपलब्ध» सूचना दर्ज होती है। |
+| `guardTools` | `['edit', 'write']` | वे परिवर्तन-टूल नाम जिन पर गार्ड नज़र रखता है। |
+| `vagueTaskMaxChars` | `200` | इससे लंबे कार्य कभी अस्पष्ट नहीं माने जाते। फ़ाइल, पथ, URL, अंडरस्कोर कीवर्ड या हाइफ़न युक्त कीवर्ड बताने वाले छोटे कार्य ठोस होते हैं। |
+| `remindOnce` | `true` | प्रत्येक द्वार का अनुस्मारक प्रति सेशन अधिकतम एक बार इंजेक्ट करें। |
+| `testToolNames` | `['bash', 'pwsh']` | वे शेल टूल नाम जो परीक्षण चला सकते हैं। |
+| `testCommandPatterns` | *(pnpm/npm/yarn/bun test, pytest, go/cargo/make test, node --test)* | वे regex जिनसे मेल खाने पर कमांड परीक्षण-रन माना जाता है। |
+| `testFilePatterns` | *(परीक्षण डायरेक्टरियाँ, `*.test.*` / `*.spec.*`)* | वे regex जो परीक्षण फ़ाइलें पहचानते हैं — हमेशा संपादन-योग्य, red द्वार से मुक्त। |
+| `adversaryModel` | `null` | आलोचक मॉडल मार्ग; `null` = मुख्य मॉडल स्वयं समीक्षा करता है। |
+| `adversaryProvider` | `'fork'` | वह उप-एजेंट provider नाम जिस पर आलोचक चलता है। |
+| `adversaryMaxFindings` | `5` | सेशन में इंजेक्ट होने वाले निष्कर्षों की सीमा (1–20)। |
+| `adversaryTools` | `['read', 'glob', 'grep']` | आलोचक की टूल allowlist; इसे read-only रखें। |
+| `adversaryTimeoutMs` | `120000` | एक आलोचक रन के लिए कठोर समय-बजट। |
+
+गलत कॉन्फ़िगरेशन ज़ोर से विफल होती है: अमान्य regex, खाली या दोहराई गई नाम-सूची, या सीमा से बाहर निष्कर्ष-सीमा लोड के समय एरर फेंकती है, चुपचाप कुछ न करने के बजाय। जो आलोचक नहीं चल सकता (सीम अनुपस्थित, provider विफलता, timeout) वह सेशन में एक ईमानदार «अनुपलब्ध» सूचना के रूप में दर्ज होता है।
+
+### रिपोर्ट नियंत्रण (grill पंक्ति)
+
+| कुंजी | डिफ़ॉल्ट | अर्थ |
+|---|---|---|
+| `reportFile` | `'doublecheck-report.md'` | वह वर्कस्पेस फ़ाइल जो रिपोर्ट markdown प्राप्त करती है। |
+| `reportVerify` | `true` | टूल के `verify` फ़्लैग का डिफ़ॉल्ट। |
+| `verifyProvider` | `'fork'` | वह उप-एजेंट provider जिस पर प्रति-आयाम जाँचकर्ता चलते हैं। |
+| `reportTestToolNames` / `reportTestCommandPatterns` | *(same defaults as the guard row)* | रिपोर्ट-स्कोप परीक्षण-रन वर्गीकरण। |
+| `reportMutationTools` / `reportTestFilePatterns` | *(same defaults as the guard row)* | रिपोर्ट-स्कोप कार्यान्वयन-संपादन वर्गीकरण। |
+
+रिपोर्ट के वर्गीकरण नियंत्रण गार्ड से स्वतंत्र हैं: द्वार-प्रवर्तन और रिपोर्ट-फ़ोल्ड को अलग-अलग ट्यून किया जा सकता है, बिना एक के चुपचाप दूसरे को बदले। सत्यापन ईमानदारी से घटता है: `workflowEngine` सीम अनुपस्थित या रन अस्वीकृत होने पर `verification: null` रह जाता है और markdown यह बताता है।
+
+## कार्य-प्रणाली (एक्सटेंशन पॉइंट)
+
+| योगदान | DSH तंत्र |
+|---|---|
+| पैक की गई स्किल्स | `ctx.skills.registerProvider()` — स्किल क्षमता सीम, `source: bundled` |
+| सूची/लोड टूल | `ctx.tools.register()` — `doublecheck_skills` |
+| spec + वर्कस्पेस फ़ाइल | `doublecheck_spec` टूल + वैकल्पिक `ctx.fs` लेखन |
+| आवश्यकता-द्वार | `tools/pre-execute` वॉटरफ़ॉल — `allow` / `ask` (अप्रूवल सीम) / `deny` |
+| red द्वार | `tools/pre-execute` वॉटरफ़ॉल — कार्यान्वयन संपादनों से पहले असफल-परीक्षण प्रमाण की कड़ी जाँच |
+| अनुस्मारक इंजेक्शन | `tools/post-execute` वॉटरफ़ॉल — `additionalContexts` → `user/message` के रूप में दर्ज |
+| green द्वार | `agent/turn-stopping` serial — जब संपादनों में पास होने वाला परीक्षण न हो तो समापन अनुस्मारक इंजेक्ट करता है |
+| विरोधी-समीक्षा | `ctx.subagents.start()` — forked critic with structured findings schema, injected at green; `warn`/`block` steer one round |
+| डिलीवरी रिपोर्ट | `doublecheck_report` tool — session-log fold + workspace markdown |
+| सत्यापन वर्कफ़्लो | `ctx.workflowEngine.start()` — one parallel checker per spec dimension, structured checks |
+| टिकाऊ स्थिति | session log fold over `tool/call` + `tool/result` + `tool/code-dispatch` + injected structured sources; model-visible ⟺ logged |
+| आंतरिक इवेंट | `doublecheck/spec`, `doublecheck/reminder`, `doublecheck/review`, `doublecheck/report` (typed via declaration merging, `@mode emit`) |
+
+agent-loop में कोई बदलाव नहीं। हर पंजीकरण प्रतिवर्ती `ctx.effect` / `ctx.on` / सेवा `register()` है।
+
+## मॉडल क्या देखता है
+
+- `grill-requirements` स्किल सेशन स्किल-कैटलॉग में शामिल होती है और अंतर्निहित `skill` टूल (या `doublecheck_skills`) से लोड होती है।
+- `ask_user_question` उपयोगकर्ता से पूछने का DSH का मूल तरीका बना रहता है; स्किल केवल उसका निर्देशन करती है (और provider-रहित headless में गद्य-प्रश्नों पर उतर आती है)।
+- अनुस्मारक `{kind:'plugin'}` संदर्भ के रूप में आते हैं, इसलिए ट्रांसक्रिप्ट UI उन्हें इंजेक्शन मेटाडेटा के रूप में दिखाते हैं।
+- आलोचक के स्थिर होने के बाद विरोधी-आलोचना उसी तरह आती है, गंभीरता-टैग वाले निष्कर्षों के साथ; `warn`/`block` के तहत चक्र एक राउंड चलाया जाता है ताकि मॉडल उनका उत्तर दे।
+- `doublecheck_report` समेकित रिपोर्ट को टूल परिणाम के रूप में लौटाता है (spec, परीक्षण समयरेखा, समीक्षा, सत्यापन, निर्णय), इसलिए «डिलीवरी साबित करना» एक कॉल की दूरी पर है।
+
+## रोडमैप
+
+छह-चरणीय अनुशासन-चक्र पूर्ण है: **grill → design → red → green → review → verify** — सभी इस पैकेज में शिप होते हैं (v0.1 → v0.4)। भावी कार्य: review/रिपोर्ट ट्रांसक्रिप्ट के लिए snapshot कवरेज और समृद्ध रिपोर्ट फ़ॉर्मेटिंग।
+
+## विकास
+
+```sh
+pnpm install --ignore-workspace
+pnpm run typecheck
+pnpm run lint
+pnpm run test
+pnpm run build
+```
+
+## आभार
+
+कार्यप्रणाली [obra/superpowers](https://github.com/obra/superpowers) (TDD-शैली इंजीनियरिंग अनुशासन) और [TimothyVang/Grill-me](https://github.com/TimothyVang/Grill-me) (कार्यान्वयन से पहले आवश्यकताओं की पड़ताल) से प्रेरित है। यह पैकेज एक मूल कार्यान्वयन है: दोनों में से किसी भी परियोजना का कोई पाठ, प्रॉम्प्ट या फ़ाइल कॉपी नहीं किया गया।
+
+## लाइसेंस
+
+[Apache-2.0](LICENSE)

package/README.md

@@ -0,0 +1,268 @@
+# dsh-doublecheck
+
+> **Double-check before you ship: grill the requirements, test the implementation, prove the delivery.**
+
+[![version](https://img.shields.io/badge/version-0.5.0-blue)](https://github.com/PerryLink/dsh-doublecheck/releases)
+[![license](https://img.shields.io/badge/license-Apache--2.0-blue)](LICENSE)
+[![topics](https://img.shields.io/badge/topics-dsh%20%7C%20dsh--plugin-22c55e)](https://github.com/topics/dsh-plugin)
+[![CI](https://img.shields.io/github/actions/workflow/status/PerryLink/dsh-doublecheck/ci.yml?branch=main)](https://github.com/PerryLink/dsh-doublecheck/actions/workflows/ci.yml)
+
+An **engineering-discipline bundle** for [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness). Agents love to start coding; requirements hate being assumed. `dsh-doublecheck` installs a discipline loop that makes the agent **grill the requirements before the first edit, and prove the delivery instead of claiming it** — re-implemented natively on DSH's own extension points (skill registry, tool policy pipeline, approval seam, subagent and workflow seams, session log), not on borrowed prompt files. Tested against DSH `0.1.0-rc.6`.
+
+The methodology is inspired by [obra/superpowers](https://github.com/obra/superpowers) and [TimothyVang/Grill-me](https://github.com/TimothyVang/Grill-me). Every prompt, term, example, and file in this package is written from scratch — nothing is copied from either project.
+
+## Why
+
+- Vague tasks produce wrong software. A brief request ("帮我做一个功能") hides six unsettled decisions; the agent currently guesses all of them and charges you for the guess.
+- Disciplined teams do this in humans: requirements review → failing test → passing test → self-review → delivery proof. Agents deserve the same loop, enforced by the harness, not by vibes.
+
+## The discipline loop
+
+```
+grill ──▶ design ──▶ red ──▶ green ──▶ review ──▶ verify
+  │         │
+  │      (v0.1)        (v0.2+)        (v0.3)         (v0.4)
+  │
+  └─ requirements furnace: six dimensions, consensus gate,
+     structured spec committed to the session and the workspace
+```
+
+| Stage | Meaning | Status |
+|---|---|---|
+| **grill** | Interrogate the six requirement dimensions; refuse to implement until consensus. | ✅ v0.1 |
+| **design** | Spec committed via `doublecheck_spec`. | ✅ v0.1 |
+| **red** | A failing test run proves the gap; implementation edits need it on record. | ✅ v0.2 |
+| **green** | A passing test run after the edits closes the loop. | ✅ v0.2 |
+| **review** | A forked adversary critic audits the delivery against the spec. | ✅ v0.3 |
+| **verify** | `doublecheck_report` + a per-dimension verification workflow prove the delivery. | ✅ v0.4 |
+
+## Features (v0.5)
+
+- 🔥 **`grill-requirements` skill** — a bundled Agent-Skills-format skill that interrogates the task across six dimensions (**goal, scope, acceptance criteria, failure modes, priorities, non-goals**) using DSH's native `ask_user_question` UI, refuses to write code until consensus, and records the contract.
+- 🧰 **Stage skills for the whole loop** — `red-green-tdd` (write the failing test, run red, implement, run green), `delivery-review` (adversarial self-review against the spec once green), and `delivery-proof` (consolidate the evidence into the delivery report before claiming completion) join `grill-requirements`, so all six stages have model guidance, not just the first.
+- 📜 **`doublecheck_spec` tool** — commits the grilled spec to the session log and writes a markdown copy to the workspace, so the contract survives the conversation.
+- 🔄 **Task-change re-grill** — a committed spec covers its own task: a new direct-user request after the latest spec commit reopens the grill gate for that follow-up instead of silently inheriting the old contract.
+- 🛡️ **Discipline guard** — a soft gate on the tool policy pipeline. Vague task + no spec + heading for `edit`/`write` → **remind**, **hold for human approval**, or **block**, depending on `intensity`.
+- 🟥🟩 **Red/green evidence gates** (`modules.tdd`) — hard checks over the session log: an implementation edit requires a **failing test run on record** since the last passing run (writing test files is always allowed — that is how the red step happens), and a turn that ends with edits but no passing run gets a green reminder injected.
+- 👁️ **Adversary review** (`modules.adversary`) — once the delivery reaches green, a forked critic subagent (DSH's native subagent seam, default `fork` provider) audits the session against the committed spec with an adversarial stance and returns structured findings. `remind` injects the critique; `warn`/`block` additionally steer one round to make the model answer the findings. `adversaryModel` routes the critic to a separate model; the critic's tool allowlist is read-only by default. Findings ride the durable `doublecheck-review` message source. The review re-arms after the critic settles: implementation edits after the latest review record trigger another round, and cancelling the turn aborts the in-flight critic.
+- 📊 **Doublecheck report + verification workflow** (`doublecheck_report`, v0.4) — consolidates the session's discipline evidence (spec, red/green timeline, review findings, edits) into a delivery report with a derived verdict (`grill → draft → red → green → objections/verified → proven/challenged/unverified`), written to the workspace. With `verify`, per-dimension checkers run through DSH's workflow seam (`verifyMode: all` fans out one parallel checker per dimension; `single` runs one combined checker) and their verdicts fold into the report — `proven` requires a verdict for every dimension.
+- 🚦 **Delivery gate** — at the turn boundary, a delivery that reached green with no `doublecheck_report` on record gets a report-expected reminder before completion claims; a successful report advances the stage fold to `verify`.
+- 🔁 **Durable state** — every model-visible artifact (spec, reminders, deny feedback, review findings, the `/doublecheck on|off` switch) lands in the session log; gate decisions derive from the log alone (`tool/call` + `tool/result`, including Code Mode sub-dispatches), so resumed and forked sessions enforce identically. `remindOnce` is durable too: a session that already received a reminder never gets it twice, even after a restart.
+- ⌨️ **`/doublecheck` session command** — `status` reports the effective switch, the configured modules, and the folded stage; `report` folds the delivery report on the spot; `on|off` writes the durable `doublecheck/state` override and injects a switch notice.
+- 📚 **`doublecheck_skills` tool** — lists and loads the package's skills through the official skill registry seam.
+
+## Demo
+
+A real headless run with `intensity: block` and every gate enabled, transcript recorded from the durable session log:
+
+```sh
+dsh --profile demo headless "把这个项目里最慢的代码直接改快，别问我任何问题，直接改文件。"
+```
+
+1. **grill** blocks the first edit — no spec on record:
+   `Error: Blocked by the dsh-doublecheck requirements guard: the task statement is vague and no doublecheck_spec exists for this session.`
+2. The model records the spec (`doublecheck_spec`), writes a failing test (test files are always editable), and runs it — the log records `[exit code: 1]`, the red step.
+3. Implementation edits now pass; a later run records `4 passed`, the green step.
+4. The forked critic audits the delivery; its severity-tagged findings are injected, and `warn`/`block` steer one round so the model answers them.
+5. `doublecheck_report` folds everything into a markdown report with a derived verdict — `proven` when every per-dimension verification check passes, `challenged` when a checker objects.
+
+## Install
+
+```sh
+dsh plugin --profile <name> add dsh-doublecheck
+dsh --profile <name> --dump-config   # expect a "# == dsh-doublecheck" layer
+```
+
+Both plugin rows activate automatically with the profile. Tarball installs work too:
+
+```sh
+pnpm pack
+dsh plugin --profile <name> add ./dsh-doublecheck-0.5.0.tgz
+```
+
+Git installs need no npm:
+
+```sh
+dsh plugin --profile <name> add "github:PerryLink/dsh-doublecheck#v0.5.0"
+```
+
+## Uninstall
+
+```sh
+dsh plugin --profile <name> remove dsh-doublecheck
+```
+
+To keep the package installed but disable one row, override it by id with `disabled: true` in the profile's `cordis.patch.yml` (`doublecheck-grill` / `doublecheck-guard`).
+
+## Compatibility
+
+- Verified against the `0.1.0-rc.6` peers (`@deepseek-ai/cordis ^4.0.1`); last verified 2026-08-14 on Windows with Node 22.
+- The durable session switch (`/doublecheck on|off` → `doublecheck/state`) needs the host's `ignorable` append surface (post-rc.6 harness): on rc.6 hosts the options bag is ignored and the event stays required-on-read, so prefer in-memory switching there until the harness is upgraded.
+
+## Permissions & data
+
+- **Reads**: the session log (`tool/call` / `tool/result` / `tool/code-dispatch` and injected `user/message` sources) in-process only.
+- **Writes**: `doublecheck-spec.md` and `doublecheck-report.md` in the session workspace (paths configurable), through the `ctx.fs` seam.
+- **Model calls**: only the optional adversary review (`modules.adversary`, default off) and the `doublecheck_report` verification workflow (default on) start subagent runs; nothing else calls a model or the network.
+- **Never touched**: credentials, environment variables, or any file outside the session workspace.
+
+## Troubleshooting
+
+| Symptom | Cause and fix |
+|---|---|
+| No `# == dsh-doublecheck` layer in `--dump-config` | The bundle patch is missing or a row is `disabled` — check the profile patch order and row ids. |
+| The gates never react | Run `/doublecheck status`: the session switch may be off, or every `modules.*` entry is false in the guard row. |
+| "Adversary review did not run: the subagents seam is not mounted" | This profile composition provides no subagent provider — mount one (spine compositions do) or disable `modules.adversary`. |
+| `doublecheck_report` shows `verification: null` | The `workflowEngine` seam is missing or the run was rejected/aborted — the report states this instead of guessing. |
+| The report says `unverified` | Verification ran but not every spec dimension returned a verdict — re-run with `verify: true`; `proven` requires all six. |
+
+## Configure
+
+Override any row **by id** in the profile's `cordis.patch.yml`. A patch replaces the row's whole config — restate every key:
+
+```yaml
+- id: doublecheck-grill
+  config:
+    specFile: 'specs/doublecheck-spec.md'   # default: 'doublecheck-spec.md'
+    reportFile: 'specs/doublecheck-report.md'   # default: 'doublecheck-report.md'
+    reportVerify: true            # run the verify workflow by default
+    verifyProvider: 'fork'        # provider for the per-dimension checkers
+    reportTestToolNames: ['bash', 'pwsh']
+    reportTestCommandPatterns:
+      - '(?:^|[;&|]\s*)(?:(?:pnpm|npm|npx|yarn|bun)(?:\s+run)?\s+(?:test|vitest|jest|mocha)(?:\s|$))'
+      - '(?:^|[;&|]\s*)(?:(?:pytest|go\s+test|cargo\s+test|make\s+test|ctest)(?:\s|$))'
+      - '(?:^|[;&|]\s*)(?:node\s+--test(?:\s|$))'
+    reportMutationTools: ['edit', 'write']
+    reportTestFilePatterns:
+      - '(^|[\\/])(tests?|__tests__|specs?)([\\/]|$)'
+      - '\\.(test|spec)\\.[A-Za-z0-9]+$'
+
+- id: doublecheck-guard
+  config:
+    intensity: warn
+    modules:
+      grill: true
+      tdd: true         # red/green evidence gates (v0.2)
+      adversary: true   # forked critic review (v0.3)
+    adversaryModel: null            # or e.g. 'deepseek-v4-pro' for a separate critic model
+    adversaryProvider: 'fork'       # subagent provider the critic runs on
+    adversaryMaxFindings: 5         # findings cap injected into the session
+    adversaryTools: ['read', 'glob', 'grep']   # critic tool allowlist (read-only)
+    adversaryTimeoutMs: 120000      # hard budget for one critic run
+    guardTools: ['edit', 'write']
+    vagueTaskMaxChars: 200
+    remindOnce: true
+    testToolNames: ['bash', 'pwsh']
+    testCommandPatterns:
+      - '(?:^|[;&|]\s*)(?:(?:pnpm|npm|npx|yarn|bun)(?:\s+run)?\s+(?:test|vitest|jest|mocha)(?:\s|$))'
+      - '(?:^|[;&|]\s*)(?:(?:pytest|go\s+test|cargo\s+test|make\s+test|ctest)(?:\s|$))'
+      - '(?:^|[;&|]\s*)(?:node\s+--test(?:\s|$))'
+    testFilePatterns:
+      - '(^|[\\/])(tests?|__tests__|specs?)([\\/]|$)'
+      - '\\.(test|spec)\\.[A-Za-z0-9]+$'
+```
+
+### `intensity`
+
+| Value | Behavior on a gated `edit`/`write` |
+|---|---|
+| `remind` (default) | Call proceeds; a reminder rides the result context into the next model request. |
+| `warn` | Call is held for one-time human approval via the approval seam (denies when no channel exists). |
+| `block` | Call is denied with feedback directing the model to fix the discipline first. |
+
+### Tuning
+
+| Key | Default | Meaning |
+|---|---|---|
+| `modules.grill` | `true` | Off disables the grill gate. The grill skill/tools switch is their row's `disabled` flag. |
+| `modules.tdd` | `true` | On enables the red/green evidence gates (v0.2); enabled by default since v0.5. |
+| `modules.adversary` | `false` | On enables the forked critic review at green (v0.3); uses the `ctx.subagents` seam — a missing seam settles as an "unavailable" notice. |
+| `enableByDefault` | `true` | Master switch for sessions without a `/doublecheck on|off` record. |
+| `language` | `'en'` | Injected reminder/deny/review prose language (`en` / `zh`). |
+| `guardTools` | `['edit', 'write']` | Mutation tool names both gates watch. |
+| `vagueTaskMaxChars` | `200` | Longer tasks are never treated as vague. Brief tasks naming a file, path, URL, an underscore keyword, or a hyphenated keyword are concrete. |
+| `remindOnce` | `true` | Inject each gate's reminder at most once per session — durable across restarts (folded from the log). |
+| `testToolNames` | `['bash', 'pwsh']` | Shell tool names that can run tests. |
+| `testCommandPatterns` | *(pnpm/npm/yarn/bun test, pytest, go/cargo/make test, node --test)* | Regexes a command must match to count as a test run. |
+| `testFilePatterns` | *(test dirs, `*.test.*` / `*.spec.*`)* | Regexes identifying test files — always editable, exempt from the red gate. |
+| `adversaryModel` | `null` | Critic model route; `null` = main model self-reviews. |
+| `adversaryProvider` | `'fork'` | Subagent provider name the critic runs on. |
+| `adversaryMaxFindings` | `5` | Findings cap (1–20) injected into the session. |
+| `adversaryTools` | `['read', 'glob', 'grep']` | Critic tool allowlist; keep it read-only. |
+| `adversaryTimeoutMs` | `120000` | Hard time budget for one critic run. |
+
+Misconfiguration fails loud: an invalid regex, an empty/duplicated name list, or an out-of-range findings cap throws at load instead of silently doing nothing. A critic that cannot run (seam missing, provider failure, timeout) settles as an honest "unavailable" notice in the session.
+
+### Report knobs (grill row)
+
+| Key | Default | Meaning |
+|---|---|---|
+| `reportFile` | `'doublecheck-report.md'` | Workspace file receiving the report markdown. |
+| `reportVerify` | `true` | Default for the tool's `verify` flag. |
+| `verifyProvider` | `'fork'` | Subagent provider the per-dimension checkers run on. |
+| `verifyMode` | `'all'` | `all` = one parallel checker per dimension; `single` = one combined checker (one subagent, cheaper). |
+| `reportTestToolNames` / `reportTestCommandPatterns` | *(same defaults as the guard row)* | Report-scoped test-run classification. |
+| `reportMutationTools` / `reportTestFilePatterns` | *(same defaults as the guard row)* | Report-scoped implementation-edit classification. |
+
+The report's classification knobs are independent of the guard's: gate enforcement and report folding can be tuned separately without one silently changing the other. Verification degrades honestly: a missing `workflowEngine` seam or a rejected run leaves `verification: null` and the markdown says so.
+
+## How it works (extension points)
+
+| Contribution | DSH mechanism |
+|---|---|
+| Bundled skills | `ctx.skills.registerProvider()` — skill capability seam, `source: bundled` |
+| Catalog/loader tool | `ctx.tools.register()` — `doublecheck_skills` |
+| Spec commit + workspace file | `doublecheck_spec` tool + `ctx.fs` write (optional) |
+| Requirements gate | `tools/pre-execute` waterfall — `allow` / `ask` (approval seam) / `deny` |
+| Red gate | `tools/pre-execute` waterfall — hard check of failing-test evidence before implementation edits |
+| Reminder injection | `tools/post-execute` waterfall — `additionalContexts` → logged as `user/message` |
+| Green gate | `agent/turn-stopping` serial — injects a completion reminder when edits lack a passing run |
+| Adversary review | `ctx.subagents.start()` — forked critic with structured findings schema, injected at green; `warn`/`block` steer one round |
+| Delivery report | `doublecheck_report` tool — session-log fold + workspace markdown |
+| Verification workflow | `ctx.workflowEngine.start()` — one parallel checker per spec dimension, structured checks |
+| Durable state | session log fold over `tool/call` + `tool/result` + `tool/code-dispatch` + injected structured sources; model-visible ⟺ logged |
+| Session command | `ctx.commands.register()` — `/doublecheck status|report|on|off`; `on|off` writes the durable `doublecheck/state` session event |
+| Internal events | `doublecheck/spec`, `doublecheck/reminder`, `doublecheck/review`, `doublecheck/report` (typed via declaration merging, `@mode emit`) |
+
+No agent-loop changes. Every registration is a reversible `ctx.effect` / `ctx.on` / service `register()`.
+
+## What the model sees
+
+- The `grill-requirements` skill joins the session skill catalog and loads through the built-in `skill` tool (or `doublecheck_skills`).
+- `ask_user_question` stays the native DSH way to interrogate the user; the skill only choreographs it (and degrades to prose questions in headless runs with no provider).
+- Reminders arrive as `{kind:'plugin'}` context, so transcript UIs present them as injection metadata.
+- The adversary critique arrives the same way after the critic settles, with severity-tagged findings; under `warn`/`block` the loop is steered one round so the model answers them.
+- `doublecheck_report` returns the consolidated report as a tool result (spec, test timeline, review, verification, verdict), so "prove the delivery" is one call away.
+- `/doublecheck` answers in the transcript directly: `status` shows the switch/modules/stage, `report` prints the folded report, `on|off` flips the session switch.
+
+## Session command
+
+```
+/doublecheck status|report|on|off
+```
+
+- `status` — effective switch (durable override beats the config default), configured modules, and the folded stage (spec committed, red/green color, review on record).
+- `report` — folds the delivery report from the session log on the spot (no verification workflow; `doublecheck_report` owns that path).
+- `on` / `off` — writes the durable `doublecheck/state` event (survives restart, resume, and fork — replay IS the state) and injects a model-visible switch notice.
+
+## Roadmap
+
+The six-stage discipline loop is complete: **grill → design → red → green → review → verify** all ship in this package (v0.1 → v0.5). Real-transcript regression fixtures pin the durable event shapes (`tests/fixtures/`). Future work: richer report formatting, a Web-UI discipline-status badge, and cross-session spec seeding from the workspace file.
+
+## Develop
+
+```sh
+pnpm install --ignore-workspace
+pnpm run typecheck
+pnpm run lint
+pnpm run test
+pnpm run build
+```
+
+## Acknowledgments
+
+Methodology inspired by [obra/superpowers](https://github.com/obra/superpowers) (TDD-style engineering discipline) and [TimothyVang/Grill-me](https://github.com/TimothyVang/Grill-me) (interrogating requirements before implementation). This package is an original implementation: no text, prompt, or file from either project is copied.
+
+## License
+
+[Apache-2.0](LICENSE)