@zh-xx/antu 0.9.0 → 0.9.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.
- package/assets/viewer.html +5 -5
- package/bin/antu-mcp.mjs +5 -5
- package/bin/antu.mjs +56 -51
- package/package.json +1 -1
- package/server.json +2 -2
- package/spec/agent/fact/guide.md +13 -13
- package/spec/agent/justification/guide.md +8 -8
- package/spec/agent/procedure/guide.md +8 -8
- package/spec/agent/relationship/guide.md +9 -9
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@zh-xx/antu",
|
|
3
|
-
"version": "0.9.
|
|
3
|
+
"version": "0.9.1",
|
|
4
4
|
"description": "Antu: legal diagrams (fact, procedure, relationship, justification) from JSON, as one offline HTML page. The command line and the MCP server.",
|
|
5
5
|
"license": "AGPL-3.0-or-later",
|
|
6
6
|
"author": "Ji Cheng",
|
package/server.json
CHANGED
|
@@ -6,12 +6,12 @@
|
|
|
6
6
|
"url": "https://github.com/zh-xx/Antu",
|
|
7
7
|
"source": "github"
|
|
8
8
|
},
|
|
9
|
-
"version": "0.9.
|
|
9
|
+
"version": "0.9.1",
|
|
10
10
|
"packages": [
|
|
11
11
|
{
|
|
12
12
|
"registryType": "npm",
|
|
13
13
|
"identifier": "@zh-xx/antu",
|
|
14
|
-
"version": "0.9.
|
|
14
|
+
"version": "0.9.1",
|
|
15
15
|
"transport": {
|
|
16
16
|
"type": "stdio"
|
|
17
17
|
}
|
package/spec/agent/fact/guide.md
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
# Mechanism notes for an agent
|
|
2
2
|
|
|
3
|
-
> This is an **operating note**, not the specification. The field list is
|
|
4
|
-
>
|
|
3
|
+
> This is an **operating note**, not the specification. The field list is a separate
|
|
4
|
+
> document, the examples are separate files, and the design rationale lives in the
|
|
5
5
|
> human-facing documents under `spec/` (you do not need them to write JSON).
|
|
6
6
|
>
|
|
7
7
|
> **This file is English on purpose.** It goes into a model's context, the same as
|
|
@@ -17,7 +17,7 @@ The reader can also switch to a **chronicle** (one column in slot order, the tim
|
|
|
17
17
|
written between events) or a **time scale** (distance is real time, the axis breaks where the
|
|
18
18
|
scale changes). `date`, `dateEnd` and their precision matter more there: a day-only date is
|
|
19
19
|
drawn as the whole day. The same JSON draws in all three; `kind: "chronicle"` or
|
|
20
|
-
`kind: "scale"` on
|
|
20
|
+
`kind: "scale"` on `layout`, `preview` and `render` shows it.
|
|
21
21
|
|
|
22
22
|
## Where an event is drawn is decided by three things
|
|
23
23
|
|
|
@@ -61,9 +61,9 @@ rules above are applied. It **never changes the data**:
|
|
|
61
61
|
|
|
62
62
|
**A time point holds at most one event per lane.** Two events in the same lane of the
|
|
63
63
|
same slot means that view cannot be drawn, and it disappears from the interface options
|
|
64
|
-
(an option that cannot be clicked is noise). `
|
|
64
|
+
(an option that cannot be clicked is noise). `validate` checks the data once and does not call
|
|
65
65
|
this an error, since a data set may keep a view that does not fit on purpose; it does list each such
|
|
66
|
-
view as a note after "Validation passed", so it never goes unseen. `
|
|
66
|
+
view as a note after "Validation passed", so it never goes unseen. `layout` reports the same views.
|
|
67
67
|
|
|
68
68
|
Three ways to fix it, most common first:
|
|
69
69
|
|
|
@@ -79,17 +79,17 @@ After splitting, check again that each slot holds exactly one event.
|
|
|
79
79
|
## After writing
|
|
80
80
|
|
|
81
81
|
```
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
82
|
+
validate reports each problem, with the field path and the event id
|
|
83
|
+
(e.g. slots[0].events[1] (ev-2)); when it passes, notes any view that
|
|
84
|
+
does not fit (not an error, but that view will not be offered)
|
|
85
|
+
layout no rendering: how large, which orientation, which views do not fit
|
|
86
|
+
preview take a screenshot and look: are cards cramped, is the text small,
|
|
87
|
+
is there too much empty space
|
|
88
|
+
render produce the self-contained HTML
|
|
89
89
|
```
|
|
90
90
|
|
|
91
91
|
**Passing validation is only the pass mark.** Validation cannot tell whether the
|
|
92
|
-
diagram looks good. Always run `
|
|
92
|
+
diagram looks good. Always run `preview` and look before delivering.
|
|
93
93
|
|
|
94
94
|
## Things that are easy to get wrong
|
|
95
95
|
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
# Mechanism notes for an agent
|
|
2
2
|
|
|
3
|
-
> This is an **operating note**, not the specification. The field list is
|
|
4
|
-
>
|
|
3
|
+
> This is an **operating note**, not the specification. The field list is a separate
|
|
4
|
+
> document, the examples are separate files, and the design rationale lives in
|
|
5
5
|
> `spec/justification/schema-draft.md` (you do not need it to write JSON).
|
|
6
6
|
>
|
|
7
7
|
> **This file is English on purpose.** It goes into a model's context, the same as
|
|
@@ -81,14 +81,14 @@ diagram that grows past about 60 nodes.
|
|
|
81
81
|
## After writing
|
|
82
82
|
|
|
83
83
|
```
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
84
|
+
validate each problem with its path and id: links[3] (f-9 -> e-9): `to` refers to ...
|
|
85
|
+
on a pass it can still add notes (a fact with no source, nothing supports a conclusion)
|
|
86
|
+
layout counts, layers, size per orientation; no rendering
|
|
87
|
+
preview a screenshot: is each issue clear, do the lines cross badly, is anything cut off
|
|
88
|
+
render the self-contained HTML
|
|
89
89
|
```
|
|
90
90
|
|
|
91
|
-
**Passing validation is only the pass mark.** Always look with `
|
|
91
|
+
**Passing validation is only the pass mark.** Always look with `preview` before delivering. A big diagram
|
|
92
92
|
(past about 40 nodes) is small on one screen: split it, one diagram per issue.
|
|
93
93
|
|
|
94
94
|
## Also easy to get wrong
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
# Mechanism notes for an agent
|
|
2
2
|
|
|
3
|
-
> This is an **operating note**, not the specification. The field list is
|
|
4
|
-
>
|
|
3
|
+
> This is an **operating note**, not the specification. The field list is a separate
|
|
4
|
+
> document, the examples are separate files, and the design rationale lives in the
|
|
5
5
|
> human-facing documents under `spec/` (you do not need them to write JSON).
|
|
6
6
|
>
|
|
7
7
|
> **This file is English on purpose.** It goes into a model's context, the same as
|
|
@@ -86,13 +86,13 @@ they are not in the data.
|
|
|
86
86
|
## After writing
|
|
87
87
|
|
|
88
88
|
```
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
89
|
+
validate each problem with its path and node id: nodes (n-4): kind is "decision" but ...
|
|
90
|
+
layout counts, layers, loops, rules, size per orientation; no rendering
|
|
91
|
+
preview a screenshot: is the main line obvious, are the branches readable
|
|
92
|
+
render the self-contained HTML
|
|
93
93
|
```
|
|
94
94
|
|
|
95
|
-
**Passing validation is only the pass mark.** Always look with `
|
|
95
|
+
**Passing validation is only the pass mark.** Always look with `preview` before
|
|
96
96
|
delivering.
|
|
97
97
|
|
|
98
98
|
## Also easy to get wrong
|
|
@@ -106,4 +106,4 @@ delivering.
|
|
|
106
106
|
|
|
107
107
|
The reader can switch to the **route map**: the main line as one line, with rework loops and early endings
|
|
108
108
|
hanging below it. It needs a clear main line, so **mark `main` along the whole line from start to end**
|
|
109
|
-
(or on none, and the engine infers it). `kind: "route"` on
|
|
109
|
+
(or on none, and the engine infers it). `kind: "route"` on `layout`, `preview` and `render` shows it.
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
# Mechanism notes for an agent
|
|
2
2
|
|
|
3
|
-
> This is an **operating note**, not the specification. The field list is
|
|
4
|
-
>
|
|
3
|
+
> This is an **operating note**, not the specification. The field list is a separate
|
|
4
|
+
> document, the examples are separate files, and the design rationale lives in
|
|
5
5
|
> `spec/relationship/schema-draft.md` (you do not need it to write JSON).
|
|
6
6
|
>
|
|
7
7
|
> **This file is English on purpose.** It goes into a model's context, the same as
|
|
@@ -23,7 +23,7 @@ relation between A and B". The **equity tree** draws the `equity` relations in l
|
|
|
23
23
|
line, so **write `share` on every equity relation**. The **authority chart** draws `control`, `employment` and `agency` as an organisation chart; the **related-party
|
|
24
24
|
list** is a table of one party's relations (to paste into a brief); the **path** draws the shortest chains between
|
|
25
25
|
two parties; the **summary** draws each camp (`groupId`) as one block. The same JSON draws in all nine;
|
|
26
|
-
`kind: "focus"`, `"chain"`, `"matrix"`, `"equity"`, `"authority"`, `"related"`, `"path"` or `"summary"` on
|
|
26
|
+
`kind: "focus"`, `"chain"`, `"matrix"`, `"equity"`, `"authority"`, `"related"`, `"path"` or `"summary"` on `layout`, `preview` and `render` shows it.
|
|
27
27
|
|
|
28
28
|
## Three things, three places
|
|
29
29
|
|
|
@@ -75,14 +75,14 @@ group (`groupId`); groups do not nest. Leave a party out of every group and it s
|
|
|
75
75
|
## After writing
|
|
76
76
|
|
|
77
77
|
```
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
78
|
+
validate each problem with its path and id: relations (r-2): `secures` points at ...
|
|
79
|
+
on a pass it can still add notes (an entity nothing relates to, shares over 100%)
|
|
80
|
+
layout counts, layers, size per orientation; no rendering
|
|
81
|
+
preview a screenshot: are the camps clear, do the lines cross badly
|
|
82
|
+
render the self-contained HTML
|
|
83
83
|
```
|
|
84
84
|
|
|
85
|
-
**Passing validation is only the pass mark.** Always look with `
|
|
85
|
+
**Passing validation is only the pass mark.** Always look with `preview` before delivering.
|
|
86
86
|
|
|
87
87
|
## Also easy to get wrong
|
|
88
88
|
|