# yammory_system
**आपका सहायक वह पूछना बंद कर देता है जो उसे पहले से पता होना चाहिए।**
वह सत्रों के पार आपको याद रखता है — हर विषय में आप किस स्तर तक हैं, आपसे किस लहज़े में बात करनी है, क्या-क्या तय हो चुका है — और आपकी अनुमोदन के बिना कोई लेखन नहीं होता, इसलिए आपके बारे में कुछ भी आपकी पीठ पीछे जमा नहीं होता।
[](LICENSE)
[](https://github.com/topics/dsh-plugin)
[](#compatibility)
[](https://github.com/KhalilYamber/yammory-system/actions)
[](https://github.com/KhalilYamber/yammory-system/releases)
[English](README.md) · [简体中文](README-zh.md) · [Español](README-es.md) · [Português](README-pt.md) · [हिन्दी](README-hi.md)
वितरण: केवल GitHub चैनल — कोई npm पैकेज नहीं, कोई मार्केटप्लेस लिस्टिंग नहीं।
---
## Why this exists
एक काबिल सहायक भी भूलने की बीमारी वाला सहायक ही रहता है। हर सत्र में वह शून्य से शुरू करता है: उसे नहीं पता कि आप eigenvector समझ चुके हैं पर tensor network कभी छुआ नहीं, कि आप तारीफ़ से पहले सुधार पसंद करते हैं, और यह भी नहीं कि तीन हफ़्ते पहले आपने वह रास्ता न चुनने का फ़ैसला किया था। तो आप खुद को बार-बार नए सिरे से परिचित कराते हैं, और जो बातचीत दिलचस्प हिस्से से शुरू हो सकती थी, वह शून्य से शुरू होती है।
`yammory_system` DeepSeek Harness को वह ज्ञान रखने की जगह देता है, और अनुमान लगाए बिना उसका उपयोग करने का तरीक़ा भी। तीन बातें इसे एक मेमोरी-भंडार से अलग करती हैं:
- **बोलने का तरीक़ा पहले तय होता है, खोज बाद में।** सात-फ़ेसट प्रोफ़ाइल में प्रति-क्षेत्र ज्ञान स्तर होता है, इसलिए जवाब देने से पहले ही सहायक को पता रहता है कि आप कौन-सी शब्दावली सँभाल सकते हैं — इंजेक्शन प्रॉम्प्ट संयोजन के समय होता है, किसी रिट्रीवल चरण के बाद नहीं।
- **आपके बिना कुछ नहीं लिखा जाता।** हर लेखन पथ सेवा के भीतर DSH के अपने अनुमोदन द्वार से गुज़रता है। अस्वीकृत लेखन भी प्रमाण छोड़ता है; चुपचाप लिखा जाना वह अवस्था नहीं जहाँ यह प्लगइन पहुँच सके।
- **उसका काम आप जाँच सकते हैं।** मॉडल ने जो-जो देखा, सब दर्ज है, भंडार एक साधारण SQLite फ़ाइल है जिसे आप ब्राउज़, निर्यात और ऑडिट कर सकते हैं, और ग़लतियों की एक पूरी श्रेणी अनुशासन से नहीं, डिज़ाइन से रुकती है।
## Install
```sh
# 1. install the bundle into your profile
dsh plugin --profile web add "github:KhalilYamber/yammory-system#main"
# 2. restart and verify the row
dsh --profile web --dump-config | grep -A3 'id: yammory_system'
```
अन्य चैनल और हटाना:
- **git चैनल** (नवीनतम `main`): `dsh plugin --profile web add git+https://github.com/KhalilYamber/yammory-system.git`.
- **tarball चैनल**: इस रेपो में `npm pack`, फिर `dsh plugin --profile web add ./yammory_system-.tgz`.
- **uninstall**: `dsh plugin --profile web remove yammory_system` (मेमोरी डेटाबेस और सत्र लॉग रखे जाते हैं)।
## The first minute
रीस्टार्ट के बाद, बिना कुछ कॉन्फ़िगर किए, आपको यह दिखना चाहिए:
| कहाँ | क्या |
|---|---|
| साइडबार का निचला हिस्सा | सेटिंग्स के बग़ल में एक **मेमोरी** प्रविष्टि (यह ड्रॉअर खोलती-बंद करती है; `panel.enabled` से छिपाई जा सकती है) |
| वार्ता शीर्षक-पट्टी | प्रति-सत्र मेमोरी स्विच — बंद करने पर उस सत्र का इंजेक्शन, रिकॉल, लेखन और अवलोकन रुक जाता है |
| साइडबार का निचला हिस्सा → वही प्रविष्टि | ड्रॉअर: ट्रैक और परत के अनुसार प्रविष्टियाँ, खोज, चेतावनी-रेखाओं का उपयोग, हाल का ऑडिट, तीन अवलोकनीय संख्याएँ, और एक **पूरी लाइब्रेरी साफ़ करें** बटन जो केवल एक मार्कर कतार में डालता है |
| DSH सेटिंग्स → `yammory-system` | हर कॉन्फ़िग फ़ील्ड, हर एक के साथ एक प्रश्नचिह्न जो उसे सरल शब्दों में समझाता है |
| `/memory` | `list`, `query`, `stats`, `audit`, `session on|off`, `export` / `import `, और भी बहुत कुछ |
## Table of contents
- [Why this exists](#why-this-exists)
- [Install](#install)
- [The first minute](#the-first-minute)
- [How it works](#how-it-works)
- [Capabilities](#capabilities)
- [Compatibility](#compatibility)
- [Configuration](#configuration)
- [Tools & surfaces](#tools--surfaces)
- [MCP server](#mcp-server)
- [Permissions & data](#permissions--data)
- [Security boundaries](#security-boundaries)
- [Known limitations](#known-limitations)
- [How it's different](#how-its-different)
- [dsh-memory-protocol v1](#dsh-memory-protocol-v1)
- [What we learned from the terminal memories](#what-we-learned-from-the-terminal-memories)
- [Development](#development)
- [Topics](#topics)
- [Contributors](#contributors)
- [Upstream](#upstream)
## How it works
`yammory_system` एक क्षमता-सीम है, कोई दूसरा भंडार नहीं: एक टाइप्ड `ctx.memory` सेवा, एक स्थानीय SQLite प्रदाता (`node:sqlite`, WAL, `0600`, `$DSH_HOME/dsh-memento/memory.db` पर) और उसके उपभोक्ता — `memory` टूल और सिस्टम प्रॉम्प्ट में इंजेक्ट किया गया फ़्रोज़न स्नैपशॉट।
दो ट्रैक × दो परतें × प्रति-एजेंट कुंजी: एक `user` ट्रैक (उपयोगकर्ता के बारे में तथ्य) और एक `agent` ट्रैक (पर्यावरण तथ्य और परंपराएँ), प्रत्येक `user-global` और `workspace` परतों में बँटा, `agentPreset` के अनुसार पृथक। स्नैपशॉट पहले प्रॉम्प्ट संयोजन पर प्रति-सत्र एक बार फ़्रीज़ होता है और सत्र के बीच कभी नहीं बदलता। वॉर्म-अप ब्लॉक अभिव्यक्ति-बाधाएँ और स्थायी प्रोफ़ाइल रखता है, और एक पंक्ति की निर्देशिका से समाप्त होता है (`N more workspace / agent-track entries stay out of this block`), ताकि मॉडल जान सके कि `memory_recall` से लाने योग्य कुछ है——केवल गिनती, सामग्री माँगने पर ही।
## Capabilities
- **अनुमोदन द्वार को टाला नहीं जा सकता।** हर लेखन पथ (`add` / `replace` / `remove` / `seed`) सेवा के भीतर अनुमोदन वॉटरफ़ॉल से होकर गुज़रता है, टूल परत से नहीं। `writePolicy: ask | auto | off` मॉडल के लिए अदृश्य विन्यास है; `replace` / `remove` / `consolidate` अनुमोदन पेलोड में बदली जाने वाली प्रविष्टियों का पूरा पाठ ले जाते हैं, और अस्वीकृत लेखन भी एक `*-denied` ऑडिट पंक्ति छोड़ता है।
- **मॉडल-दृश्य ⟺ लॉग किया गया।** इंजेक्ट किया गया स्नैपशॉट `system/message` में शब्दशः पहुँचता है; हर लेखन `approval/asked` + `approval/decided` + प्लगइन की अपनी ऑडिट तालिका से पुनर्निर्माण-योग्य है।
- **परिबद्ध और ईमानदार।** प्रति-ट्रैक/प्रति-परत कोमल चेतावनी-रेखाएँ (डिफ़ॉल्ट user 2000 / agent 4000)। रेखा पार करने पर लेखन कभी नहीं रुकता — केवल संकेत मिलता है कि वह परत समेकित करने योग्य है। कभी काटा नहीं, कभी स्वतः संकुचित नहीं।
- **प्रति-सत्र स्विच।** हर सत्र का अपना मेमोरी स्विच (प्लगइन का अपना SQLite टेबल, स्कीमा v6; डिफ़ॉल्ट रूप से चालू)। बंद करने पर चार चीज़ें एक साथ रुकती हैं: इंजेक्शन (जमा हुआ वॉर्म-अप ब्लॉक तुरंत हट जाता है), रिकॉल (`SESSION_MEMORY_OFF`), लेखन (अनुमोदन द्वार की उसी परत पर अस्वीकृत) और अवलोकन (सत्र स्कैन नहीं होता, इतिहास में भी नहीं चुना जाता)। प्रबंधन-पठन (`/memory list` / `budgets` / `audit` / `export`) उपलब्ध रहते हैं। `/memory session on|off` या कंपोज़र के स्विच से बदलें; स्विच की स्थिति कभी सत्र लॉग में नहीं जाती और उसकी ऑडिट पंक्तियों में `text: null` रहता है।
- **देखना, और देखने को ख़ुद चलने देना।** अवलोकन चैनल आपके ही पुराने संदेशों का एक सीमित हिस्सा पढ़ता है और ऐसी व्यवहार-प्रविष्टियाँ लिखता है जो प्रश्नावली तक नहीं पहुँचती; अब एक केवल-पढ़ने वाली जाँच बताती है कि पिछला अवलोकन एक सप्ताह से अधिक पुराना है (एक `observe-due` ऑडिट पंक्ति और अगले वार्म-अप ब्लॉक के अंत में एक पंक्ति), और साप्ताहिक निर्धारित राउंड इसे एक ही कार्यक्षेत्र में बिना किसी की मौजूदगी के चला सकता है: एक हेडलेस `dsh` सत्र स्कैन करता है, अधिकतम तीन साक्ष्य-सहित प्रविष्टियाँ निकालता है और उन्हें उसी अनुमोदन द्वार से लिखता है, जिसकी अनुमति उसका अपना राइट-पॉलिसी स्रोत (`source:observation`, `auto` / `ask` / `off`) देता है। प्लगइन के अंदर कोई टाइमर नहीं रहता; शेड्यूल एक Windows Task Scheduler प्रविष्टि है, ठीक सफ़ाई राउंड की तरह।
- **सफ़ाई और माप।** मॉडल द्वारा चलाई गई सफ़ाई उन प्रविष्टियों को, जो एक ही बात कहती हैं, `merged` टैग वाली एक प्रविष्टि में मिला देती है और पुरानी को `superseded` कर देती है: वे डिस्क पर रहती हैं, किसी भी सत्र की दृश्य-सूची से बाहर, कभी मिटाई नहीं जातीं। यह कभी बाल्टी नहीं लाँघती (`track × scope × agentKey`, workspace परत पर साथ में `workspaceKey`) और कभी अपने आप नहीं चलती। कोई विलय बिना किसी व्यक्ति के लिखा जा सकता है या नहीं, यह पाँच यांत्रिक कसौटियाँ तय करती हैं (एक ही बकेट / सदस्य संख्या / विराम-चिह्न, रिक्त स्थान और प्रतीक हटाने के बाद अक्षरशः समानता / समानता-स्कोर / कवरेज), मॉडल का स्वयं घोषित भरोसा नहीं: केवल वही श्रेणी `auto` मानी जाती है जिसके सदस्य विराम-चिह्न, रिक्त स्थान और प्रतीक हटाने पर समान हों, और वह बिना किसी की निगरानी में लिखी जा सकती है, जबकि पूरी तरह पुनर्लिखित समानार्थी जोड़ी `review` रेखा से भी नीचे रहती है और सीधे `skip` मानी जाती है, तथा एक अक्षर का बदलाव `review` में जाता है और इंटरैक्टिव रास्ता माँगता है। इसलिए एक पृष्ठभूमि दौर (आपके ही शेड्यूलर द्वारा जगाई गई हेडलेस `dsh` सत्र) यांत्रिक रूप से निर्विवाद दोहराव स्वयं मिला सकती है, और बाकी आपकी प्रतीक्षा में छोड़ देती है। लेखन अपना ऑडिट स्रोत स्वयं पिन करता है (`tidy-auto`), इसलिए बारीक लेखन-नीति (`source:tidy-auto`) ठीक उसी एक रास्ते को खोल सकती है और शेष लेखन स्वीकृति द्वार के पीछे रहते हैं। अलग से, `agent/turn-stopping` पर एक केवल-पठन जाँच केवल यह बताती है कि बैकलॉग रेखा पार कर गया (एक `tidy-due` ऑडिट पंक्ति और अगले वॉर्म-अप ब्लॉक के अंत में एक पंक्ति)। `/memory stats` तीन अवलोकनीय संख्याएँ बताता है (पुनरावृत्ति दर, रिकॉल हिट दर, इंजेक्शन मात्रा), और पैनल में वही तीन पंक्तियाँ दिखती हैं; सफलता दर जानबूझकर खाली छोड़ी गई है, क्योंकि इस रिपॉज़िटरी के पास «इंजेक्ट किया गया ब्लॉक वाकई समझा गया?» का कोई संकेत-स्रोत नहीं है। पैनल का **पूरी लाइब्रेरी साफ़ करें** बटन एक कतार है, क्रिया नहीं: यह उसी अनुमोदन नीति के तहत एक ही मार्कर पंक्ति (`tidy_requests`, schema v7) लिखता है, अगले सत्र का वॉर्म-अप मॉडल से पूरी लाइब्रेरी की सफ़ाई माँगता है, और जब सचमुच कोई सफ़ाई-लेखन होता है तब मार्कर `done` हो जाता है: पैनल से कुछ भी विलीन नहीं होता।
- **मेमोरी का शासन: रद्द की गई प्रविष्टि वापस लाएँ, टकराव का फ़ैसला फ़ेसट के अनुसार करें।** `restore` रद्दीकरण को उलटी दिशा में ले जाता है (`superseded → active`, `version` अपरिवर्तित, हर सत्र की दृश्य-सूची में वापस) और रद्द अवस्था से निकलने का यही एकमात्र रास्ता है। `arbitrate` उस स्थिति का फ़ैसला करता है जहाँ एक ही तथ्य के दो स्रोत हों: फ़ैसला **एक ही फ़ेसट** पर होता है और दिशा एक निश्चित तालिका से आती है — क्षमता अवलोकन की बात मानती है, पसंद स्वयं-कथन की, और शेष पाँच फ़ेसट **दोनों** प्रविष्टियाँ रखती हैं और हर एक पर `gap` टैग लगाती हैं (अंतर ही साक्ष्य है)। तालिका ही दिशा है, इसलिए उलटा तर्क देने का कोई रास्ता नहीं, और एक समूह के भीतर सबसे हाल में अद्यतन प्रविष्टि रखी जाती है। दोनों क्रियाएँ उसी अनुमोदन द्वार, उसी प्रति-सत्र स्विच और उन्हीं बाल्टी नियमों से गुज़रती हैं जिनसे हर लेखन, और दोनों ऑडिट छोड़ती हैं: `restore` प्रति प्रविष्टि, `arbitrate` प्रति रद्दीकरण (`text: null`, केवल id), `arbitrate-tag` प्रति टैग, और अंत में एक `arbitrate` सारांश जो बताता है कौन रखा गया, कौन रद्द हुआ और क्यों।
## Compatibility
| Surface | Status |
|---|---|
| Harness | DeepSeek Harness `dsh-v0.1.5-rc.2` (2026-09-09 को अनुकूलित): सत्र लिफ़ाफ़ा अपना ignorable फ़ील्ड केवल संग्रहीत-लॉग पठन संगतता के लिए रखता है - Session.append अभी भी इसे स्टैम्प नहीं कर सकता, इसलिए गेट व्यवहार अपरिवर्तित है। dsh-v0.1.5-rc.2 master checkout के विरुद्ध 2026-09-11 को सत्यापित (पूर्ण गेट शृंखला + प्रोफ़ाइल इंस्टॉल स्मोक)। |
| Node | `^22.19.0 || >=24.0.0` |
| Platforms | Windows / macOS / Linux (केवल host; कोई नेटिव कोड नहीं, कोई नेटवर्क नहीं) |
| Model | कोई भी |
## Configuration
सभी ट्यूनेबल Schemastery `Config` फ़ील्ड हैं (cordis.yml से बदले जा सकते हैं)। अमान्य मान लोड पर ज़ोर से विफल होते हैं। `yammory_system` पंक्ति के अंतर्गत ओवरराइड करें।
**सेटिंग्स पैनल।** DSH सेटिंग्स सेवा माउंट होने पर नीचे के सभी फ़ील्ड (`enabled` को छोड़कर) DSH सेटिंग्स साइडबार की प्लगइन **`yammory-system` प्रविष्टि** से संपादित होते हैं (General या Plugins जैसा एक शीर्ष-स्तरीय खंड); बदलाव सेटिंग्स यूज़र लेयर (`settings.yaml`) में जाते हैं, फ़ाइल छूने की ज़रूरत नहीं। लगभग सब लाइव लागू होते हैं (राइट पॉलिसी, भाषा, बजट, सीमाएँ, प्रस्ताव, पैनल; `dbPath` / `auditRetentionDays` स्टोर पुनः खोलकर; `retrieval.vector` रिट्रीवर बदलकर) — केवल `snapshotOrder` को DSH रीलोड चाहिए। सेटिंग्स सेवा के अभाव में सब कुछ संयुक्त cordis कॉन्फ़िग पर लौटता है, पहले जैसा। साइडबार के निचले हिस्से की मेमोरी प्रविष्टि उसी पृष्ठ से छिपाई जा सकती है (`panel.enabled`)।
| Key | Default | Meaning |
|---|---|---|
| `enabled` | `true` | मुख्य स्विच; `false` सेवा, टूल, स्नैपशॉट, कमांड, पैनल और answerer हटा देता है (सेटिंग्स पृष्ठ से संपादन योग्य नहीं — अक्षम प्लगइन की कोई सेटिंग्स प्रविष्टि नहीं) |
| `panel.enabled` | `true` | साइडबार के निचले हिस्से की मेमोरी प्रविष्टि दिखाएँ; सेटिंग्स पृष्ठ से `false` सेव करने पर वह तुरंत छिप जाती है, रीलोड की ज़रूरत नहीं (सेटिंग्स पृष्ठ अप्रभावित) |
| `dbPath` | `''` → `$DSH_HOME/dsh-memento/memory.db` | निरपेक्ष, या `$DSH_HOME` के सापेक्ष (Windows पर `~/.dsh` पर फ़ॉलबैक) |
| `budgets.user.userGlobal` | `2000` | user ट्रैक की user-global परत की अक्षर चेतावनी रेखा |
| `budgets.user.workspace` | `2000` | user ट्रैक की workspace परत की अक्षर चेतावनी रेखा |
| `budgets.agent.userGlobal` | `4000` | agent ट्रैक की user-global परत की अक्षर चेतावनी रेखा |
| `budgets.agent.workspace` | `4000` | agent ट्रैक की workspace परत की अक्षर चेतावनी रेखा |
| `writePolicy` | `'ask'` | डिफ़ॉल्ट लेखन नीति: `ask` / `auto` / `off` (मॉडल-अदृश्य) |
| `writePolicies` | `{}` | प्रति-ट्रैक/स्कोप या प्रति-स्रोत ओवरराइड (जैसे `user/workspace`, `source:claude`) |
| `language` | `'en'` | मॉडल-दृश्य और कमांड आउटपुट भाषा: `en` / `zh` |
| `snapshotOrder` | `-50` | स्नैपशॉट अनुभाग क्रम (harness पहचान के बाद, persona से पहले) |
| `maxEntriesPerQuery` | `20` | डिफ़ॉल्ट प्रति-क्वेरी परिणाम सीमा (कठोर सीमा 1000) |
| `commandListLimit` | `50` | प्रति `/memory list` / `query` प्रदर्शित प्रविष्टियाँ |
| `commandAuditLimit` | `10` | प्रति `/memory audit` प्रदर्शित ऑडिट पंक्तियाँ |
| `recall.historyLimitDefault` | `8` | `memory_recall` द्वारा डिफ़ॉल्ट स्कैन किए गए सत्र |
| `recall.snippetCap` | `5` | `memory_recall` में प्रति-सत्र स्निपेट |
| `recall.snippetChars` | `300` | `memory_recall` स्निपेट अक्षर |
| `recall.windowDays` | `30` | `memory_recall` की दिनों में हाल-समय विंडो |
| `observe.days` | `14` | `memory_observe scan` की दिनों में विंडो (कठोर सीमा 90) |
| `observe.sessions` | `8` | प्रति स्कैन नमूने के रूप में लिए गए हाल के सत्र (कठोर सीमा 20) |
| `observe.perSession` | `12` | प्रति सत्र नमूने के रूप में लिए गए संदेश, समान अंतराल पर—ताकि शुरुआत और बाद के सुधार दोनों बचे रहें (कठोर सीमा 20) |
| `observe.messageChars` | `400` | अंडरस्कोर से काटने से पहले प्रति संदेश अक्षर सीमा (कठोर सीमा 800) |
| `observe.totalChars` | `12000` | पूरे स्लाइस का अक्षर बजट; वहीं रुकता है और जो कवर नहीं हुआ वह बताता है (कठोर सीमा 30000) |
| `recall.weighting.heat` | `0.3` | हीट बोनस की ऊपरी सीमा (गुणात्मक; `0` = बंद)। हीट = रिकॉल (संतृप्त) × अंतिम रिकॉल के बाद की अर्ध-आयु क्षय: हीट बनाए रखने के लिए लगातार रिकॉल होते रहना ज़रूरी है |
| `recall.weighting.heatSaturation` | `10` | हीट बोनस संतृप्त करने वाले रिकॉल |
| `recall.weighting.heatHalfLifeDays` | `14` | हीट अर्ध-आयु (दिन) |
| `recall.weighting.freshness` | `0.2` | ताज़गी बोनस की ऊपरी सीमा (गुणात्मक; `0` = बंद) |
| `recall.weighting.freshnessHalfLifeDays` | `30` | ताज़गी अर्ध-आयु (दिन) |
| `recall.weighting.tagDiscount` | `0.5` | टोकन का भार जब वह केवल `tags` में मिले (मुख्य पाठ में मिलने पर `1`) |
| `retrieval.vector` | `false` | सिमेंटिक रिकॉल स्विच: `true` वेक्टर रिकॉल तभी चालू करता है **जब वास्तव में सिमेंटिक एम्बेडिंग प्रदाता पंजीकृत हो** — हैश/फ़ेक प्रदाता जानबूझकर पर्याप्त नहीं, क्योंकि वह अर्थ का मॉडल नहीं करता और CJK रिकॉल चुपचाप शून्य कर देगा। अन्यथा शून्य-निर्भरता keyword रिट्रीवर बना रहता है (CJK बाइग्राम, किसी भी टोकन पर मिलान, हीट/ताज़गी भार, प्रासंगिकता क्रम) |
| `panelEntriesLimit` | `200` | वेब पैनल प्रविष्टि पृष्ठ आकार |
| `panelAuditLimit` | `20` | वेब पैनल डिफ़ॉल्ट ऑडिट पंक्तियाँ |
| `auditRetentionDays` | `0` | ऑडिट अवधारण (0 = हमेशा रखें) |
| `proposals.enabled` | `true` | हर सफल संघनन के बाद स्वतः एक मेमोरी प्रस्ताव कैप्चर करें |
| `proposals.maxChars` | `2000` | प्रस्ताव अक्षर सीमा |
| `proposals.maxPending` | `8` | लंबित प्रस्ताव सीमा |
## Tools & surfaces
| Surface | Kind | Notes |
|---|---|---|
| `memory` | tool | Save/Skip मार्गदर्शन के साथ add/replace/remove/consolidate/supersede/auto-tidy/restore/arbitrate/query/tidy; प्रविष्टियाँ वैकल्पिक प्रोफ़ाइल निर्देशांक रख सकती हैं (`facet` = सात में से एक, `level` = प्रति-क्षेत्र ज्ञान स्तर); `supersede` 1..20 प्रविष्टियों को `merged` टैग वाली एक प्रविष्टि में मिलाता है और पुरानी को `superseded` कर देता है (रखी जाती हैं, कभी मिटाई नहीं जातीं), `restore` रद्द की गई प्रविष्टि वापस लाता है, `arbitrate` एक फ़ेसट पर दो स्रोतों के टकराव का फ़ैसला निर्धारित तालिका की दिशा से करता है, `tidy` केवल-पठन योजना देता है; लेखन अनुमोदन द्वार से गुज़रता है |
| `memory_profile` | tool | 31 उप-क्षेत्रों के पैमाने पर प्रति-क्षेत्र ज्ञान स्तर (`set` / `list` / `get`); `set` अनुमोदन द्वार से गुज़रता है और ऑडिट होता है, `tier` `level` से निकलता है |
| `yammory-survey` | skill | उपयोगकर्ता द्वारा शुरू की गई प्रोफ़ाइल प्रश्नावली, 24 प्रश्नावली-योग्य उप-खंडों को कवर करती है; `memory` + `memory_profile` से लिखती है। स्रोत: `skills/yammory-survey/` |
| `memory_recall` | tool | परिबद्ध मेमोरी मिलान (क्वेरी टोकनयुक्त: CJK बाइग्राम, लैटिन शब्द ज्यों के त्यों; कोई भी टोकन मिलने पर रिकॉल, प्रासंगिकता क्रम में) + हाल के सत्र-इतिहास मिलान |
| `memory_observe` | tool | अवलोकन चैनल: `scan` उपयोगकर्ता के अपने पुराने संदेशों का परिबद्ध स्लाइस पढ़ता है (केवल-पठन, `cwd` से सीमित, सिस्टम-इंजेक्टेड छद्म संदेश छाँटे और गिने जाते हैं, बजट की कमी बताई जाती है); `commit` एक ही अनुमोदन वाले परमाणु बैच में साक्ष्य-सहित 1..8 प्रविष्टियाँ लिखता है, `source: observation` के साथ |
| `yammory-observe` | skill | उपयोगकर्ता द्वारा शुरू किया गया व्यवहार-अवलोकन, जो पाँच केवल-अवलोकन पक्षों (सोच शैली, कठिनाई में चरित्र, भावनात्मक पैटर्न, आत्म-छवि, निर्णय शैली) को `memory_observe` से लिखता है। स्रोत: `skills/yammory-observe/` |
| `yammory-tidy` | skill | उपयोगकर्ता द्वारा शुरू की गई मेमोरी-सफ़ाई: केवल-पठन योजना पढ़ता है, जो एक ही बात कहती हैं उन्हें एक में मिलाता है और पुरानी प्रविष्टियों को `superseded` कर देता है (रखी जाती हैं, कभी मिटाई नहीं जातीं), बाल्टी कभी नहीं लाँघता। स्रोत: `skills/yammory-tidy/`; निर्णय-नियम `references/merge-rules.md` में |
| `yammory-experience` | skill | काम की पुनरुपयोगी सीखों को `agent` ट्रैक (पर्यावरण-तथ्य, परंपराएँ, सबक़) में दर्ज करता है, उपयोगकर्ता प्रोफ़ाइल से एक ही प्रश्न पर अलग: क्या यह जानकारी हर बार मौजूद रहनी चाहिए? स्रोत: `skills/yammory-experience/` |
| `/memory` | command | `list` · `query` · `add` · `remove` · `consolidate` · `restore ` · `arbitrate ` · `tidy [--days=N]` · `stats` · `proposals` · `budgets` · `audit` · `export` · `import ` · `adapters` · `observe [--days=N]` · `session [on|off]` |
| session switch | session header | वार्ता शीर्षक-पट्टी में, एजेंट प्रीसेट लेबल के ठीक बाद प्रति-सत्र मेमोरी स्विच (`conversation.session.header.actions`, सत्र स्कोप): वर्तमान स्थिति दिखाता है और `GET`/`POST /api/memento/session` से बदलता है (पैनल रूटों वाली वही `connection.fetch` भरोसा-बाड़) |
| web panel | client drawer | केवल-पठन, दो दुनियाओं में बँटा: **मेमोरी** टैब सात-पक्षीय संकुचनशील वृक्ष है (पहले श्रेणियाँ, क्लिक पर प्रविष्टियाँ) और एक ज्ञान-स्तर ब्लॉक; **अनुभव** टैब `agent` ट्रैक को विषय के अनुसार बाँटता है। दोनों में खोज, बजट बार, तीन अवलोकनीय संख्याएँ और ऑडिट पूँछ साझा हैं; एक उपयोगकर्ता-क्रिया बटन केवल पूरी लाइब्रेरी की सफ़ाई कतार में डालता है; साइडबार प्रविष्टि छिपाई जा सकती है (`panel.enabled`) |
| settings section | DSH सेटिंग्स साइडबार → `yammory-system` | फ़ाइल छुए सभी कॉन्फ़िग फ़ील्ड संपादित करें (`enabled` को छोड़कर); लाइव/रीलोड समय पृष्ठ पर अंकित |
## MCP server
`yammory_system` एक केवल-पठन stdio **MCP सर्वर** (`yammory_system-mcp`) भी देता है ताकि बाहरी MCP क्लाइंट (Claude, Codex, …) बिना harness के मेमोरी स्टोर खोज सकें। यह newline-delimited JSON (NDJSON) पर JSON-RPC 2.0 बोलता है — प्रति पंक्ति एक JSON ऑब्जेक्ट, कोई `Content-Length` फ़्रेमिंग नहीं।
**केवल-पठन।** डेटाबेस `node:sqlite` के `readOnly: true` से खुलता है (कोई माइग्रेशन नहीं, कोई WAL लेखन नहीं, recall-count में वृद्धि नहीं); अगर फ़ाइल मौजूद नहीं है तो क्रैश के बजाय खाली परिणाम मिलते हैं।
| टूल | उद्देश्य |
|---|---|
| `memory_search` | `{query, limit?}` → क्रमबद्ध प्रविष्टियाँ (retrieval Provider seam से केस-इनसेंसिटिव सबस्ट्रिंग) |
| `memory_stats` | `{}` → `{total, namespaces}` प्रविष्टि गणना + track/scope अवलोकन |
सीधे चलाएँ:
```sh
node bin/mcp-server.mjs
# या, GitHub चैनल से पैकेज इंस्टॉल होने के बाद: npx yammory_system-mcp
# (यह रेपो अभी npm रजिस्ट्री पर नहीं है; ऊपर का -p github:… ही स्रोत है)
```
डेटाबेस पथ `$DSH_MEMENTO_DB_PATH` है (निरपेक्ष, या `$DSH_HOME` के सापेक्ष); डिफ़ॉल्ट `$DSH_HOME/dsh-memento/memory.db`।
Claude Desktop (`claude_desktop_config.json`) उदाहरण:
```json
{
"mcpServers": {
"yammory_system": {
"command": "npx",
"args": ["-y", "-p", "github:KhalilYamber/yammory-system", "yammory_system-mcp"],
"env": {
"DSH_MEMENTO_DB_PATH": "/home/you/.dsh/dsh-memento/memory.db"
}
}
}
}
```
सर्वर केवल-पठन है: कोई नेटवर्क नहीं, कोई लेखन नहीं, कोई अनुमोदन द्वार नहीं — केवल खोज और आँकड़े।
## Permissions & data
- **Permissions**: workshop मैनिफ़ेस्ट `harness:tool`, `filesystem:read`, `filesystem:write` और `network:none` / `subprocess:none` / `shell:none` / `python:none` / `credentials:none` घोषित करता है। लेखन अनुमोदन आधिकारिक अनुमोदन सीम पर चलता है।
- **Data**: स्थानीय SQLite डेटाबेस (`0600`), शून्य नेटवर्क, शून्य क्रेडेंशियल।
- **Session log**: ऑडिट पूर्णता अनुमोदन जोड़ी (`approval/asked` + `approval/decided`) और प्लगइन की अपनी ऑडिट तालिका से आती है।
## Security boundaries
- **केवल सार्वजनिक सेवाएँ।** `tools`, `systemPrompt` और अनुमोदन सीम का उपभोग करता है; engine / agent-loop / apiproxy / आधिकारिक UI में कोई बदलाव नहीं।
- **शून्य नेटवर्क, शून्य क्रेडेंशियल।** POSIX फ़ाइल मोड `0600` वाला स्थानीय डेटाबेस।
- **ज़ोर से विफल।** दूषित DB, नया स्कीमा या अमान्य विन्यास लोड पर विफल होता है; भरे बजट और अस्पष्ट सबस्ट्रिंग मिलान संरचित त्रुटियों से विफल होते हैं।
- **एक प्रक्रिया, एक भंडार।** कई सत्र SQLite भंडार साझा करते हैं; एक ही `$DSH_HOME` साझा करने वाली दो प्रक्रियाएँ एक ही फ़ाइल लिखती हैं (SQLite लॉकिंग के तहत अंतिम-लेखक-जीत)।
## Known limitations
- **सत्र घटनाएँ घोषित हैं, अभी उत्सर्जित नहीं (rc.2)।** `memory/added|updated|removed|recalled|snapshot` मर्ज-घोषित हैं, परंतु rc.2 में रेपो-बाहर घटना प्रकारों के लिए कोई पंजीकरण सतह नहीं है; harness बिल्ड उन्हें पंजीकृत करते ही उत्सर्जन चालू हो जाता है।
- **`ask` नीति को answerer चाहिए।** बिना UI/ACP answerer के, लेखन बंद-विफल होते हैं।
- **कोई FTS5 अनुक्रमण नहीं।** सबस्ट्रिंग खोज केस-असंवेदी `instr` पर चलती है (CJK के लिए सही)।
- **अवलोकन एक श्वेतसूची है, और श्वेतसूची की एक सीमा है।** `memory_observe scan` केवल वे `user/message` इवेंट रखता है जिनका `source.kind` `user` या `user-rpc` है; इस मशीन पर मापा गया कि इससे सभी `user/message` इवेंट का 48% हट जाता है (रनटाइम संदर्भ, AGENTS.md, skill सूचियाँ, goal राउंड, सबएजेंट सूचनाएँ)। परन्तु यह किसी व्यक्ति द्वारा लिखे संदेश को उस बाहरी ब्रिज-इंजेक्ट संदेश से अलग नहीं कर सकता जो स्वयं को `kind: 'user'` भी कहता है——लॉग में बस यही एक संकेत है। एक अकेले उद्धरण को कमज़ोर साक्ष्य मानें; निष्कर्ष के लिए सत्रों में पुनरावृत्ति चाहिए।
- **«सिमेंटिक» कहलाने वाला रिकॉल का आधा हिस्सा अभी सिमेंटिक नहीं है।** `retrieval.vector` तभी काम करता है जब कोई ऐसा एम्बेडिंग प्रदाता पंजीकृत हो जो स्वयं को सिमेंटिक घोषित करे, और यहाँ जो एकमात्र प्रदाता भेजा गया है वह `false` घोषित करता है, इसलिए आज यह स्विच डिज़ाइन के अनुसार keyword रिकॉल पर लौट आता है। सच्चा सिमेंटिक रिकॉल चालू करने के लिए एक ऐसा एम्बेडिंग स्रोत चाहिए जिसे इस रिपॉज़िटरी ने अभी चुना नहीं है।
## How it's different
| Plugin | यह क्या है | yammory_system का अंतर |
|---|---|---|
| dsh-mneme | स्व-विकसित मेमोरी, विस्तृत फ़ीचर-सतह | केवल छोटे-कोर्पस प्रोफ़ाइल: यह उपयोगकर्ता के मापे गए स्तर पर बोलकर अलग दिखता है, फ़ीचर बढ़ाकर नहीं |
| dsh-meow-memory | सात-परत स्टोर, BM25 रिट्रीवल | कोई रिट्रीवल इंजीनियरिंग नहीं: प्रति-क्षेत्र स्तर तालिका और फ़ेसेट मध्यस्थता |
| dsh-persona-memory | प्रॉम्प्ट में पर्सोना इंजेक्शन | एक परत आगे: स्थायी प्रोफ़ाइल के ऊपर **प्रति-क्षेत्र ज्ञान स्तर** और **फ़ेसेट मध्यस्थता** |
| dsh-memory-evolve | मेमोरी वेयरहाउस / इवोल्यूशन लूप | टाइप्ड सेवा सीम, अनुमोदन द्वार और सत्र-लॉग ऑडिट; कोई वेयरहाउस महत्वाकांक्षा नहीं |
| dsh-mnemon | मेमोरी स्टोर सहायक | प्रोटोकॉल + द्वार + ऑडिट, कोई दूसरा स्टोर नहीं |
| dsh-kb-sieve | ज्ञान-आधार छानना | कोई रिट्रीवल इंजीनियरिंग नहीं: छोटे-कोर्पस सबस्ट्रिंग खोज, `session_search`/`sessionQuery` से क्रॉस-सेशन रिकॉल |
| dsh-tdai-memory | कार्य-संचालित मेमोरी टूलिंग | बजट प्रति track×परत और सेवा में लागू, न कि सर्वोत्तम-प्रयास |
| claude-bridge | Claude Code ब्रिजिंग | DSH-नेटिव; भविष्य का `seed(source:'claude')` पथ एक ब्रिज को वही स्टोर भरने देता है |
| dsh-external/Recall | बाहरी एजेंट मेमोरी | स्थानीय-प्रथम, शून्य-नेटवर्क, DSH की अपनी अनुमोदन सीम पर चलता है |
| Official MCP memory examples | DSH की घोषित "मेमोरी = बाहरी MCP" स्थिति | **नेटिव फर्स्ट-पार्टी** पूरक: समान लक्ष्य, कोई बाहरी सर्वर नहीं; दोनों सह-अस्तित्व |
आज जो दो अंतर टिकते हैं वे तालिका की आख़िरी जोड़ी हैं: **प्रति-क्षेत्र ज्ञान स्तर वाली सात-फ़ेसेट प्रोफ़ाइल** (किसी भी रिट्रीवल से पहले तय करती है कि सहायक किस लहज़े में बोले) और **फ़ेसेट मध्यस्थता** (एक ही तथ्य के दो स्रोतों का फ़ैसला कैसे हो: क्षमता अवलोकन मानती है, प्राथमिकता स्व-कथन मानती है, बाक़ी पाँच फ़ेसेट दोनों रखते हैं और हर एक पर `gap` लगाते हैं)।
नाम **`yammory_system`** है (GitHub चैनल से इंस्टॉल; अभी npm रजिस्ट्री पर नहीं)। `dsh-recall` नहीं (dsh-external/Recall से भ्रमित होने वाला), न ही हटाया गया विरासत नाम `dsh-memory`।
## dsh-memory-protocol v1
`yammory_system` DSH मेमोरी प्रोटोकॉल का सामुदायिक पूर्वाभ्यास है — एक आधिकारिक `ctx.memory` सीम के लिए उम्मीदवार आकार। यह प्रोटोकॉल इस प्लगइन की सीम को एक क्रॉस-प्लगइन अनुबंध में सामान्य करता है:
- **Entry spec** — दो ट्रैक × दो परतें × प्रति-एजेंट कुंजी, साथ ही छोटे `tags` (≤16 × ≤32 अक्षर) और प्रति-प्रविष्टि `version` जो हर `replace` पर बढ़ता है।
- **Write semantics** — इडेम्पोटेंट अद्वितीय-सबस्ट्रिंग सशर्त लेखन; जो-दिखे-वही-स्वीकृत पेलोड (`replace` / `remove` / `consolidate` बदले जाने वाला पूरा पाठ ले जाते हैं)।
- **Audit contract** — हर लेखन `approval/asked` + `approval/decided` + प्रदाता खाता-बही से पुनर्निर्माण-योग्य।
- **चेतावनी रेखा मॉडल** — परत-वार अक्षर चेतावनी रेखा / `AMBIGUOUS_MATCH` अर्थविज्ञान।
- **Schema versioning** — ज़ोरदार संस्करण जाँच वाले प्रवासन नियम।
- **Spec** — [docs/protocol-v1.md](docs/protocol-v1.md) (中文: [protocol-v1.zh.md](docs/protocol-v1.zh.md)); मानक JSON Schema [docs/schemas/dsh-memory-protocol-v1.schema.json](docs/schemas/dsh-memory-protocol-v1.schema.json) पर।
**Adapter registry** — `ctx.memoryAdapters` (`register` / `list` / `adapt` / `export`) तृतीय-पक्ष मेमोरी प्लगइन को एक शुद्ध डेटा कन्वर्टर पंजीकृत करके प्रोटोकॉल बोलने देता है (उत्क्रमणीय `register()`; आयात अनुमोदन-द्वारी `seed` पर चलता है, निर्यात केवल-पठन है)। ऑनबोर्डिंग: [docs/adapters-guide.md](docs/adapters-guide.md) (中文: [adapters-guide.zh.md](docs/adapters-guide.zh.md))।
| Built-in adapter | External format | Notes |
|---|---|---|
| `mem0` | mem0 तथ्य संग्रह (`{facts: [{memory, metadata?}]}`) | `metadata.category` / `metadata.tags` tags बनते हैं; कच्चे `messages` ऐरे अस्वीकृत — एडेप्टर परिवर्तित करते हैं, कभी निष्कर्षण नहीं |
| `hermes-memory-md` | Hermes `memory.md` (`## section` + बुलेट) | अनुभाग नाम tags बनते हैं; बिना बुलेट वाला गद्य ज़ोर से विफल होता है |
| `claude-code-memory-md` | `CLAUDE.md`-शैली markdown (शीर्षक, बुलेट, अनुच्छेद) | बुलेट और अनुच्छेद प्रविष्टियाँ बनते हैं; अनुभाग नाम tags बनते हैं |
**Conformance suite** — [test/protocol-conformance/](test/protocol-conformance/README.md): एक वितरण-योग्य केस-सेट जिसे संगतता का दावा करने वाला कोई भी प्रदाता चलाता है (`node test/protocol-conformance/run.mjs --provider ./your-factory.mjs`); इस रेपो का CI इसे अपने प्रदाता के विरुद्ध स्वर्ण संदर्भ के रूप में चलाता है (`npm run test:conformance`)।
- **Upstream proposal** — [docs/upstream-proposal.md](docs/upstream-proposal.md) (中文: [upstream-proposal.zh.md](docs/upstream-proposal.zh.md)): आधिकारिक `ctx.memory` सीम को प्रोटोकॉल क्यों अपनाना चाहिए, अंतर और प्रवासन पथ।
## What we learned from the terminal memories
`yammory_system` Claude Code, Codex या Hermes का पोर्ट नहीं है — लेकिन इसके डिज़ाइन ने जान-बूझकर वह अपनाया जो प्रत्येक ने सही किया, और वह अस्वीकार किया जो नुकसान करता था:
| Terminal memory | क्या सही किया | yammory_system ने क्या अपनाया |
|---|---|---|
| **Claude Code** — `CLAUDE.md` | पदानुक्रमित सादा-पाठ मेमोरी फ़ाइलें (उपयोगकर्ता-स्तर → परियोजना-स्तर), मानव-पठनीय और संपादन-योग्य, हर सत्र में स्वतः मर्ज | सादा-पाठ प्रविष्टियाँ; `user-global` / `workspace` परतें प्रति-सत्र मर्ज; एक भंडार जिसे आप ब्राउज़, `export` और ऑडिट कर सकते हैं — पारदर्शिता एक विशेषता के रूप में |
| **Codex** — `AGENTS.md` | प्रति-निर्देशिका स्कोप्ड निर्देश स्वतः खोजे और शून्य मॉडल घर्षण से इंजेक्ट | सत्र cwd से अनुक्रमित `workspace` परत (Windows केस-असंवेदी); सत्र आरंभ पर स्वतः इंजेक्ट फ़्रोज़न स्नैपशॉट |
| **Hermes** — `memory.md` | सक्रिय मेमोरी सेव और यह सुरक्षा सबक कि केवल टूल परत पर लागू द्वार देर से टूल-इंजेक्शन से टाला जा सकता है | Save/Skip मार्गदर्शन वाला `memory` टूल + अनुमोदन-द्वारी स्वतः-कैप्चर प्रस्ताव; द्वार `ctx.memory` के लेखन तरीकों के भीतर रहता है, टूल परत में नहीं |
स्रोत: [Claude Code memory](https://code.claude.com/docs/en/memory) · [Codex AGENTS.md](https://developers.openai.com/codex/cli/agents-md) · [Hermes memory](https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/features/memory.md) · [Hermes #48181](https://github.com/NousResearch/hermes-agent/issues/48181)।
और जान-बूझकर अस्वीकार किए गए भाग: मॉडल-निजी स्थिति में छिपा स्व-सारांशीकरण (यहाँ संघनन सारांश **लंबित प्रस्ताव** बनते हैं जो मानव approve/dismiss की प्रतीक्षा करते हैं), भंडार/वेक्टर-स्टोर महत्वाकांक्षाएँ, और बिना मानव-दृश्य अनुमोदन या ऑडिट ट्रेल वाला कोई भी लेखन। यह भी अपनाया गया: Hermes की दस्तावेज़ित चेतावनी कि एक ही होम निर्देशिका साझा करने वाली दो प्रक्रियाएँ एक ही मेमोरी फ़ाइल लिखती हैं — Security boundaries देखें।
## Development
```sh
npm install # node ^22.19 || >=24
npm test # node --test: 365 tests
npm run lint # oxlint
npm run test:conformance # dsh-memory-protocol v1 conformance suite
npm run typecheck # tsc --checkJs gate
npm run check:coverage # line-coverage gate
npm run check:readmes # five-language README consistency gate
npm run verify:self-contained # reject out-of-repo dependency specs
npm run verify:artifacts # artifact presence + syntax + import
```
`lib/` में शून्य DSH निर्भरता है (केवल node: बिल्टइन); DSH आयात केवल `index.mjs` में मौजूद हैं।
## Topics
`dsh`, `dsh-plugin`, `deepseek-harness`, `memory`, `agent-memory`, `approval`, `audit`, `sqlite`, `cordis`, `llm`
## Contributors
- [@Niuniu-Sir](https://github.com/Niuniu-Sir) — [issue #1](https://github.com/PerryLink/dsh-memento/issues/1) में बूट-क्रैश रिपोर्ट, जिससे 0.3.1 में `~/.dsh` फ़ॉलबैक आया।
## Upstream
This project is a fork of [`dsh-memento`](https://github.com/PerryLink/dsh-memento), originally part of the [PerryLink DSH plugin family](https://github.com/PerryLink). Upstream attribution and the Apache-2.0 licence are preserved.
[Apache License 2.0](LICENSE) © 2026 dsh-memento contributors