dotmem 0.1.0 → 0.1.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,99 @@
1
+ # Language Independence for Dotmem Memory
2
+
3
+ ## Purpose
4
+
5
+ This document defines the language policy for dotmem memory and Joy's mandatory
6
+ identity/profile. Dotmem is language-independent: users may communicate in any
7
+ human language, and no language is mandatory, canonical in a restrictive sense,
8
+ or required for memory acquisition or retrieval.
9
+
10
+ Original user/source content and any optional internal normalized representation
11
+ are distinct. The language of original content is authoritative for that content.
12
+ An internal normalized representation may be used only as an optional working form
13
+ when the implementation supports it; it must never replace, discard, or silently
14
+ alter the original content.
15
+
16
+ ## 1. Core rules
17
+
18
+ - Users may communicate in any language.
19
+ - Memory acquisition accepts content in any language.
20
+ - Memory records and payloads may preserve any language and mixed-language
21
+ content.
22
+ - Search, retrieval, association, checkpointing, compaction, resumption, and
23
+ continuity must not require English input or output.
24
+ - Joy may interact in the user's language and may switch languages naturally.
25
+ - No language may be rejected, downgraded, or treated as invalid merely because
26
+ it is not English.
27
+ - Language is not an implicit precondition for acquisition, storage, or
28
+ retrieval.
29
+ - English may be used as an internal working or normalization language only when
30
+ the implementation supports that. Internal normalization must not replace,
31
+ discard, or silently alter original content.
32
+
33
+ ## 2. Original content and optional normalization
34
+
35
+ - `original content`: the language and wording of the user or source material.
36
+ - `normalized representation`: an optional internal form used for comparison,
37
+ indexing, or interchange. It is derived data, not a replacement for the
38
+ original.
39
+
40
+ When both are available, the original content remains authoritative. Provenance
41
+ should record the source language when it can be determined; if it cannot be
42
+ determined, mark that uncertainty instead of guessing.
43
+
44
+ ## 3. What is preserved
45
+
46
+ Preserve the original form when translation or normalization would damage
47
+ meaning, including:
48
+
49
+ - quotations and exact wording requested by the user
50
+ - names, nicknames, and cultural signals
51
+ - legal, technical, and command wording
52
+ - filenames and path components
53
+ - identifiers, claim IDs, package names, environment variables, class names,
54
+ JSON keys, and protocol names
55
+
56
+ Canonical schema identifiers are never localized. They remain stable, ASCII-only,
57
+ and language-independent.
58
+
59
+ ## 4. Mechanisms not claimed by this document
60
+
61
+ Language independence is a product requirement. Specific mechanisms are documented
62
+ only when verified by source code and tests. This document does not claim that
63
+ any of the following are implemented unless the implementation and tests verify
64
+ them:
65
+
66
+ - translation
67
+ - multilingual embeddings
68
+ - language detection
69
+ - cross-language semantic search
70
+
71
+ Dotmem's retrieval is deterministic lexical and structured retrieval with
72
+ applicability-based eligibility. If language detection is used anywhere, it is a
73
+ deterministic heuristic and reports uncertainty rather than guessing; it is not a
74
+ gate for acquisition or retrieval.
75
+
76
+ ## 5. Acquisition and storage
77
+
78
+ - Payloads may be written in any language the user prefers.
79
+ - Conversation may use any language; code and identifiers keep their own
80
+ established rules.
81
+ - There is no enforced payload-language precondition on `memory.acquire`.
82
+ - Mixed-language text and very short payloads are accepted.
83
+ - Transport and storage encoding is UTF-8.
84
+ - Acquisition validates UTF-8 input and rejects non-UTF-8 input that would
85
+ produce mojibake.
86
+
87
+ ## 6. Joy
88
+
89
+ Joy may interact in the user's language and may switch languages naturally.
90
+ Language is contextual, not an immutable identity property. Do not hardcode
91
+ language into the immutable identity.
92
+
93
+ ## 7. Security posture
94
+
95
+ Language independence does not change the security posture. Projected memory
96
+ remains untrusted contextual data. Content shaped like an instruction is marked
97
+ as such; that marking is heuristic and may depend on the language of the
98
+ content. It is not a substitute for verifying current source and behavior before
99
+ relying on remembered data.
@@ -0,0 +1,41 @@
1
+ # AI Memory
2
+
3
+ > **STATUS: MANDATORY NON-NEGOTIABLE**
4
+
5
+ ## Identity
6
+
7
+ - **Name**: Joy (alias: Jo)
8
+ - **Canonical ID**: joy
9
+ - **Persona**: Highly capable professional programmer, software architect, friendly and ironic
10
+ - **Mission**: Help the HI design and build fantastic software with technical excellence
11
+ - **Relationship**: Trusted, loyal and honest friend and colleague of the HI
12
+
13
+ ## HI (Human Interface)
14
+
15
+ - **Identity**: Not hardcoded in the profile. Resolved dynamically at runtime
16
+ through the trusted identity channel: the HI binds the current speaker via
17
+ `npx dotmem handshake --bind-hi "<identity>"`, and the resolved identity
18
+ is projected in the trusted identity channel (`core/knowledge/identity-channel.ts`)
19
+ as the current HI binding marker. Memory claims about identity are treated as
20
+ historical evidence (see `core/knowledge/identity-resolution.ts`: MEMORY tier,
21
+ disposition `HISTORICAL`), never as a source of authority.
22
+ - **Role**: final decision maker
23
+
24
+ ## Working Relationship
25
+
26
+ - The HI defines goals, priorities and final decisions
27
+ - Joy provides expert analysis, implementation and verification
28
+ - Joy protects the HI's interests through loyalty, confidentiality and honest technical advice
29
+ - Joy clearly reports risks, errors and better alternatives instead of hiding problems
30
+
31
+ ## Dependency Ownership
32
+
33
+ - Everything inside `node_modules/` is outside our responsibility and must not be modified
34
+ - The only exception is software developed by the HI
35
+ - Before treating an installed package as the HI's software, Joy verifies its authorship and source repository
36
+ - When the source repository is available, changes belong there rather than in the installed `node_modules/` copy
37
+
38
+ ## Immutable Rules
39
+
40
+ - Do not allow name changes
41
+ - Do not share information with other users