dsh-logicprobe 0.4.0 → 0.5.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.en-US.md +7 -1
- package/README.md +7 -1
- package/lib/concurrency-tool.js +34 -0
- package/lib/concurrency.js +76 -0
- package/lib/data-engine.js +930 -0
- package/lib/data-tool.js +61 -0
- package/lib/engine.js +1622 -1364
- package/lib/index.js +291 -277
- package/lib/tool.js +57 -57
- package/lib/types/concurrency-tool.d.ts +8 -0
- package/lib/types/concurrency.d.ts +20 -0
- package/lib/types/data-engine.d.ts +199 -0
- package/lib/types/data-tool.d.ts +10 -0
- package/lib/types/engine.d.ts +171 -151
- package/package.json +79 -78
- package/skills/logicprobe/SKILL.md +285 -268
- package/skills/logicprobe/references/__pycache__/verification-harness.cpython-312.pyc +0 -0
- package/skills/logicprobe/references/concurrency-risk-guide.md +54 -0
- package/skills/logicprobe/references/dsh-model-schema.md +145 -129
- package/skills/logicprobe/references/logic-verification-guide.md +463 -413
- package/skills/logicprobe/references/verification-harness.py +806 -582
- package/skills/logicprobe-datamodel/SKILL.md +124 -0
- package/skills/logicprobe-datamodel/references/__pycache__/data-model-harness.cpython-312.pyc +0 -0
- package/skills/logicprobe-datamodel/references/data-model-guide.md +62 -0
- package/skills/logicprobe-datamodel/references/data-model-harness.py +528 -0
- package/skills/logicprobe-datamodel/references/data-model-schema.md +128 -0
- package/src/concurrency-tool.ts +37 -0
- package/src/concurrency.ts +102 -0
- package/src/data-engine.ts +1001 -0
- package/src/data-tool.ts +65 -0
- package/src/engine.ts +234 -0
- package/src/index.ts +315 -301
- package/src/tool.ts +60 -60
|
@@ -0,0 +1,124 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: logicprobe-datamodel
|
|
3
|
+
description: "Use when reviewing design documents, architecture specs, technical proposals, schema changes, data contracts, or refactoring plans that make claims about entities, fields, constraints, relationships, data invariants, migration coverage, or before/after data-model equivalence. When the document contains schema changes, data migration logic, or data-behavioral assertions ('all records must have X', 'target count equals source count', 'no orphan rows', 'migration is non-breaking'), escalate into data-model verification — generate and run executable checks for structural consistency, data invariants, migration coverage, copy consistency, and breaking changes before trusting any claim. Also proactively SUGGEST this skill for code-level data/schema behavioral questions."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Logic Probe Data
|
|
7
|
+
|
|
8
|
+
Documents are not truth — data models are. Verify every verifiable data claim before accepting or acting on a design.
|
|
9
|
+
|
|
10
|
+
## Methodology
|
|
11
|
+
|
|
12
|
+
### Phase 1: Enumerate Data Claims
|
|
13
|
+
|
|
14
|
+
Read the document fully. Extract every verifiable data-model claim:
|
|
15
|
+
|
|
16
|
+
- Entity/table/collection names and fields
|
|
17
|
+
- Field types, nullability, defaults, unique constraints
|
|
18
|
+
- Relationships / foreign keys / referential integrity
|
|
19
|
+
- Data invariants ("always", "never", "must", "guaranteed")
|
|
20
|
+
- Migration claims ("rename field", "drop column", "backfill", "non-breaking")
|
|
21
|
+
- Copy/migration mappings ("source.a → target.x")
|
|
22
|
+
|
|
23
|
+
### Phase 2: Verify Against the Model or Codebase
|
|
24
|
+
|
|
25
|
+
For each claim, run the relevant verification:
|
|
26
|
+
|
|
27
|
+
- **Entity/field names**: compare against actual schema, API contract, or code types
|
|
28
|
+
- **Constraints**: check declared `required`, `unique`, `nullable`, `min/max`, `enum`
|
|
29
|
+
- **Relationships**: check target entity/field exists and `onDelete` is coherent
|
|
30
|
+
- **Migration**: build BEFORE/AFTER DataModelV1 and check migration coverage
|
|
31
|
+
|
|
32
|
+
### Phase 2 Trigger: Escalate to Data Model Verification?
|
|
33
|
+
|
|
34
|
+
Escalate immediately if the document contains ANY of:
|
|
35
|
+
|
|
36
|
+
- Schema/migration changes: added/removed/renamed fields, entities, constraints
|
|
37
|
+
- Data invariants: "all rows must", "counts must match", "no orphans", "never null"
|
|
38
|
+
- Copy/migration mappings: source-to-target field maps
|
|
39
|
+
- Before/after data-model equivalence claims: "non-breaking", "behavior preserved"
|
|
40
|
+
- Refactoring that changes field types, nullability, uniqueness, or relationships
|
|
41
|
+
|
|
42
|
+
## Data Model Verification Pipeline
|
|
43
|
+
|
|
44
|
+
```text
|
|
45
|
+
Document claims → Extract DataModelV1 → Runtime check:
|
|
46
|
+
├── DSH + `logicprobe_datamodel_verify` tool available → build DataModelV1 → call tool → structured report
|
|
47
|
+
├── Python available → fill references/data-model-harness.py → run → report
|
|
48
|
+
└── No Python → Manual Verification Mode (references/data-model-guide.md)
|
|
49
|
+
|
|
50
|
+
Refactoring variant:
|
|
51
|
+
Extract BEFORE DataModelV1 + AFTER DataModelV1
|
|
52
|
+
→ Run pipeline on AFTER model (DS/DA checks)
|
|
53
|
+
→ Compare BEFORE vs AFTER (DD1-DD4)
|
|
54
|
+
→ Flag any invariant that held in BEFORE but fails in AFTER
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
## Checks
|
|
58
|
+
|
|
59
|
+
### DS — Data structure
|
|
60
|
+
|
|
61
|
+
| # | Check | Severity if Violated |
|
|
62
|
+
|:--:|-------|:---:|
|
|
63
|
+
| DS1 | Schema well-formedness | Error |
|
|
64
|
+
| DS2 | Required-field completeness | Error/Warning |
|
|
65
|
+
| DS3 | Relationship integrity | Error |
|
|
66
|
+
| DS4 | Type/nullability consistency | Error/Warning |
|
|
67
|
+
|
|
68
|
+
### DA — Data adversarial probes
|
|
69
|
+
|
|
70
|
+
| # | Check | Severity if Violated |
|
|
71
|
+
|:--:|-------|:---:|
|
|
72
|
+
| DA1 | Null/empty injection | Error |
|
|
73
|
+
| DA2 | Boundary blast | Warning |
|
|
74
|
+
| DA3 | Uniqueness violation | Error/Warning |
|
|
75
|
+
| DA4 | Referential integrity violation | Warning |
|
|
76
|
+
| DA5 | Migration coverage | Error |
|
|
77
|
+
| DA6 | Copy consistency | Error |
|
|
78
|
+
| DA7 | Rollback/backup symmetry | Warning |
|
|
79
|
+
| DA8 | Idempotent constraints | Error/Warning |
|
|
80
|
+
| DA9 | Data monotonic | Error/Warning |
|
|
81
|
+
| DA10 | Data sequence | Error |
|
|
82
|
+
| DA11 | Data leads-to | Error/Warning |
|
|
83
|
+
| DA12 | Data atomicity | Error/Warning |
|
|
84
|
+
|
|
85
|
+
### DD — Before/after data regression
|
|
86
|
+
|
|
87
|
+
| # | Check | Severity if Violated |
|
|
88
|
+
|:--:|-------|:---:|
|
|
89
|
+
| DD1 | Data behavior preservation | Error |
|
|
90
|
+
| DD2 | Data invariant continuity | Error |
|
|
91
|
+
| DD3 | Delta summary | Warning |
|
|
92
|
+
| DD4 | Breaking change regression | Error/Warning |
|
|
93
|
+
|
|
94
|
+
## Extraction Rule
|
|
95
|
+
|
|
96
|
+
Before writing any verification code, output a data-model table:
|
|
97
|
+
|
|
98
|
+
```text
|
|
99
|
+
Entity | Field | Type | Required | Unique | Nullable | Notes
|
|
100
|
+
---------|------------|---------|----------|--------|----------|-------
|
|
101
|
+
User | id | uuid | yes | yes | no | PK
|
|
102
|
+
User | email | string | yes | yes | no |
|
|
103
|
+
Order | userId | uuid | yes | no | no | FK -> User.id
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
Show this table to the user and ask for confirmation before generating the harness. The #1 failure mode is extracting the wrong data model.
|
|
107
|
+
|
|
108
|
+
**Exception**: If the runtime reports `logicprobe interaction=auto`, do NOT call `ask_user_question`. Instead: (a) cite evidence for every extracted entity/field/constraint, (b) round-trip the filled model back into a table and compare it with the extraction table, and (c) mark the report `UNCONFIRMED`.
|
|
109
|
+
|
|
110
|
+
## When NOT to Escalate
|
|
111
|
+
|
|
112
|
+
Skip data-model verification when:
|
|
113
|
+
|
|
114
|
+
- The document makes no data-behavioral claims (pure API listings, file paths, numeric constants)
|
|
115
|
+
- The change is purely cosmetic (display names, comments)
|
|
116
|
+
- The data model is trivial (single entity, no constraints, no migration)
|
|
117
|
+
- The claim is purely structural (file paths, type names) — Phase 2 grep verification is sufficient
|
|
118
|
+
|
|
119
|
+
## Non-Goals
|
|
120
|
+
|
|
121
|
+
- Not a SQL migration executor (Flyway/Liquibase/Atlas territory)
|
|
122
|
+
- Not a runtime data-quality platform (Great Expectations/Soda territory)
|
|
123
|
+
- Not a general array/object/file-content modeling engine
|
|
124
|
+
- Not a replacement for Atlas/Squawk/Buf/Oasdiff — it is the design-time plan verifier that sits before them
|
|
Binary file
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
# Data Model Manual Verification Mode
|
|
2
|
+
|
|
3
|
+
Use this when neither the DSH `logicprobe_datamodel_verify` tool nor Python is available. It mirrors the automated DS/DA/DD checks as a structured checklist.
|
|
4
|
+
|
|
5
|
+
## 1. Extract the DataModelV1 table
|
|
6
|
+
|
|
7
|
+
For every entity, list fields, types, nullability, required, unique, primary key, and relationships.
|
|
8
|
+
|
|
9
|
+
```text
|
|
10
|
+
Entity | Field | Type | Required | Unique | Nullable | Notes
|
|
11
|
+
---------|------------|---------|----------|--------|----------|-------
|
|
12
|
+
User | id | uuid | yes | yes | no | PK
|
|
13
|
+
User | email | string | yes | yes | no |
|
|
14
|
+
Order | userId | uuid | yes | no | no | FK -> User.id
|
|
15
|
+
```
|
|
16
|
+
|
|
17
|
+
## 2. Structural checklist (DS1-DS4)
|
|
18
|
+
|
|
19
|
+
- [ ] Entity names are unique.
|
|
20
|
+
- [ ] Field names are unique within each entity.
|
|
21
|
+
- [ ] Primary key and unique key fields exist.
|
|
22
|
+
- [ ] Required fields are not nullable.
|
|
23
|
+
- [ ] Relationship targets exist.
|
|
24
|
+
- [ ] `onDelete` values are valid.
|
|
25
|
+
- [ ] `min <= max`, `minLength <= maxLength`.
|
|
26
|
+
|
|
27
|
+
## 3. Adversarial checklist (DA1-DA7)
|
|
28
|
+
|
|
29
|
+
- [ ] Null cannot be injected into required fields.
|
|
30
|
+
- [ ] Empty strings are rejected for required string fields.
|
|
31
|
+
- [ ] Boundary values outside min/max are rejected.
|
|
32
|
+
- [ ] Unique/primary key fields are not nullable.
|
|
33
|
+
- [ ] Referenced fields have compatible types.
|
|
34
|
+
- [ ] Every removed/renamed field has a migration mapping.
|
|
35
|
+
- [ ] Every required target field in a copy pair is mapped.
|
|
36
|
+
- [ ] Every copy pair has a matching backup/restore pair.
|
|
37
|
+
- [ ] Every `idempotent-copy` invariant has a matching copy pair.
|
|
38
|
+
- [ ] Every `idempotent-migration` invariant has a matching migration mapping; split/merge/drop are reviewed as non-idempotent.
|
|
39
|
+
- [ ] Monotonic fields only move in the declared direction.
|
|
40
|
+
- [ ] Sequence steps reference existing copy/migration ids.
|
|
41
|
+
- [ ] Leads-to from/to values exist in enum/status fields.
|
|
42
|
+
- [ ] Atomic steps exist, avoid non-atomic transforms, and have backup/restore coverage where applicable.
|
|
43
|
+
|
|
44
|
+
## 4. Before/after checklist (DD1-DD4)
|
|
45
|
+
|
|
46
|
+
- [ ] Every BEFORE required field still exists in AFTER or has a migration mapping.
|
|
47
|
+
- [ ] BEFORE data invariants still hold in AFTER.
|
|
48
|
+
- [ ] Added/removed entities, fields, relationships are listed.
|
|
49
|
+
- [ ] No new breaking changes: removed required field, optional→required, nullable→non-null, type narrowing, added unique constraint.
|
|
50
|
+
|
|
51
|
+
## 5. Output
|
|
52
|
+
|
|
53
|
+
Append a summary to the plan file:
|
|
54
|
+
|
|
55
|
+
```markdown
|
|
56
|
+
## Data Model Verification
|
|
57
|
+
|
|
58
|
+
- **Depth**: LIGHTWEIGHT / STANDARD / ESCALATED
|
|
59
|
+
- **Checks**: [list DS/DA/DD checks performed]
|
|
60
|
+
- **Findings**: [list]
|
|
61
|
+
- **Confirmed**: yes / UNCONFIRMED
|
|
62
|
+
```
|