@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/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@zh-xx/antu",
3
- "version": "0.9.0",
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.0",
9
+ "version": "0.9.1",
10
10
  "packages": [
11
11
  {
12
12
  "registryType": "npm",
13
13
  "identifier": "@zh-xx/antu",
14
- "version": "0.9.0",
14
+ "version": "0.9.1",
15
15
  "transport": {
16
16
  "type": "stdio"
17
17
  }
@@ -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 served by
4
- > `antu_schema`, examples by `antu_examples`, and the design rationale lives in the
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 antu_layout / antu_preview / antu_render shows it.
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). `antu_validate` checks the data once and does not call
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. `antu_layout` reports the same views.
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
- antu_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
- antu_layout no rendering: how large, which orientation, which views do not fit
86
- antu_preview take a screenshot and look: are cards cramped, is the text small,
87
- is there too much empty space
88
- antu_render produce the self-contained HTML
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 `antu_preview` and look before delivering.
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 served by
4
- > `antu_schema`, examples by `antu_examples`, and the design rationale lives in
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
- antu_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
- antu_layout counts, layers, size per orientation; no rendering
87
- antu_preview a screenshot: is each issue clear, do the lines cross badly, is anything cut off
88
- antu_render the self-contained HTML
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 `antu_preview` before delivering. A big diagram
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 served by
4
- > `antu_schema`, examples by `antu_examples`, and the design rationale lives in the
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
- antu_validate each problem with its path and node id: nodes (n-4): kind is "decision" but ...
90
- antu_layout counts, layers, loops, rules, size per orientation; no rendering
91
- antu_preview a screenshot: is the main line obvious, are the branches readable
92
- antu_render the self-contained HTML
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 `antu_preview` before
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 antu_layout / antu_preview / antu_render shows it.
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 served by
4
- > `antu_schema`, examples by `antu_examples`, and the design rationale lives in
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 antu_layout / antu_preview / antu_render shows it.
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
- antu_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
- antu_layout counts, layers, size per orientation; no rendering
81
- antu_preview a screenshot: are the camps clear, do the lines cross badly
82
- antu_render the self-contained HTML
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 `antu_preview` before delivering.
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