memhtml 0.2.5 → 0.3.0
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.
- package/README.md +1 -1
- package/dist/{dist-Uj47oBRC.mjs → dist-B3yDga97.mjs} +2049 -297
- package/dist/dist-B3yDga97.mjs.map +1 -0
- package/dist/{dist-t84Q_98w.mjs → dist-CSo_XRfz.mjs} +2 -2
- package/dist/{dist-t84Q_98w.mjs.map → dist-CSo_XRfz.mjs.map} +1 -1
- package/dist/{dist-Dj-MYf9q.mjs → dist-FgNX_rxc.mjs} +1 -1
- package/dist/memhtml-mcp.mjs +5 -5
- package/dist/memhtml-mcp.mjs.map +1 -1
- package/dist/memhtml.mjs +7 -7
- package/dist/memhtml.mjs.map +1 -1
- package/package.json +1 -1
- package/state-migrations/S0002_entity_corroboration.sql +55 -0
- package/dist/dist-Uj47oBRC.mjs.map +0 -1
package/package.json
CHANGED
|
@@ -0,0 +1,55 @@
|
|
|
1
|
+
-- The corroboration counter on a machine-proposed ENTITY MERGE, the second one-way door that earns a
|
|
2
|
+
-- place in the durable plane.
|
|
3
|
+
--
|
|
4
|
+
-- Sleep's entity resolution asks a model to partition one entity type's names into identity clusters.
|
|
5
|
+
-- A proposal the model makes with no external evidence is a guess, and acting on it renames every
|
|
6
|
+
-- `memhtml-entity` meta across the corpus and fuses two subjects' memories permanently — there is no
|
|
7
|
+
-- inverse commit that separates them again. So a merge the model alone proposes is COUNTED here on the
|
|
8
|
+
-- night it is seen and applied only once `detections >= 2`, meaning two different nights reached the
|
|
9
|
+
-- same conclusion over independently re-read corpora.
|
|
10
|
+
--
|
|
11
|
+
-- The same discipline `state.edge_corroboration` holds for a machine-detected `contradicts`, and for
|
|
12
|
+
-- the same reason: the counter is derived, high-churn, and gates a write into the files, so it belongs
|
|
13
|
+
-- in the plane that is gitignored and re-exported rather than in the memory files themselves. Once the
|
|
14
|
+
-- merge is applied the rewrite is file-borne and this row is decoration.
|
|
15
|
+
--
|
|
16
|
+
-- A merge backed by a DECLARED alias never reaches this table. A person file stating
|
|
17
|
+
-- `<meta name="memhtml-alias" content="laith">` is a human's (or an authoritative directory's)
|
|
18
|
+
-- assertion of identity, not a machine's suspicion, so it applies on the first night.
|
|
19
|
+
--
|
|
20
|
+
-- Known and accepted: the ORIENTATION is part of the key, so a merge whose direction flips restarts the
|
|
21
|
+
-- counter. The phase's weight-then-lexicographic rule reads the corpus's own file counts, and those churn
|
|
22
|
+
-- as memories are written and evicted — so a night that counted `laith -> laith al-saadoon` and a later
|
|
23
|
+
-- night that reaches `laith al-saadoon -> laith` are two rows at one detection each, and neither
|
|
24
|
+
-- promotes. That is the safe direction to be wrong in: a corpus whose weights are still moving has not
|
|
25
|
+
-- settled which name is canonical, and a merge recorded under one orientation and applied under the other
|
|
26
|
+
-- would rewrite every meta toward a name a later night disagrees with.
|
|
27
|
+
|
|
28
|
+
CREATE TABLE state.entity_corroboration (
|
|
29
|
+
-- Keyed on the merge, not on a file. An entity name is a value in a `memhtml-entity` meta and
|
|
30
|
+
-- appears on many files, so the pair being corroborated is `(alias_name -> canonical_name)` within
|
|
31
|
+
-- one `entity_type`. `person:api` and `service:api` are two different subjects whose names collide,
|
|
32
|
+
-- so the type is part of the key rather than a column beside it.
|
|
33
|
+
entity_type TEXT NOT NULL,
|
|
34
|
+
-- The name that would be REWRITTEN AWAY, normalized (lowercased, whitespace-collapsed) exactly as
|
|
35
|
+
-- the phase normalizes before comparing. Storing the raw authored form would make `Checkout API` and
|
|
36
|
+
-- `checkout api` two counters for one merge, and neither would ever reach two detections.
|
|
37
|
+
alias_name TEXT NOT NULL,
|
|
38
|
+
-- The name that would SURVIVE, normalized. Which of the two this is follows from the phase's own
|
|
39
|
+
-- weight-then-lexicographic rule and never from the model's choice, so the row records the merge the
|
|
40
|
+
-- code would perform rather than the one the model described.
|
|
41
|
+
canonical_name TEXT NOT NULL,
|
|
42
|
+
detections INTEGER NOT NULL DEFAULT 1 CHECK (detections >= 1),
|
|
43
|
+
confirmed INTEGER NOT NULL DEFAULT 0 CHECK (confirmed IN (0,1)),
|
|
44
|
+
promoted INTEGER NOT NULL DEFAULT 0 CHECK (promoted IN (0,1)),
|
|
45
|
+
updated_at TEXT NOT NULL,
|
|
46
|
+
PRIMARY KEY (entity_type, alias_name, canonical_name)
|
|
47
|
+
);
|
|
48
|
+
-- The schema name goes on the INDEX, not on the table: `CREATE INDEX x ON state.entity_corroboration
|
|
49
|
+
-- (...)` is a syntax error on this driver, while `CREATE INDEX state.x ON entity_corroboration (...)`
|
|
50
|
+
-- is accepted and lands the index in the attached schema. Unqualified `entity_corroboration` resolves
|
|
51
|
+
-- within it. (The same fact S0001 records for `state.access`.)
|
|
52
|
+
--
|
|
53
|
+
-- The lookup this serves is "every pending merge for one type", which the phase reads to report how
|
|
54
|
+
-- many proposals are waiting on a second night.
|
|
55
|
+
CREATE INDEX state.entity_corroboration_pending ON entity_corroboration (entity_type, promoted);
|