@milehimikey/em 1.19.4 → 1.19.6
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/.claude/skills/event-modeling/SKILL.md +1 -1
- package/.claude/skills/event-modeling-conform/SKILL.md +1 -1
- package/.claude/skills/event-modeling-conform/reference/conform.md +2 -1
- package/.claude/skills/event-modeling-design/SKILL.md +1 -1
- package/.claude/skills/event-modeling-discover/SKILL.md +1 -1
- package/.claude/skills/event-modeling-engagement/SKILL.md +1 -1
- package/.claude/skills/event-modeling-implement/SKILL.md +1 -1
- package/.claude/skills/event-modeling-implement/reference/implement.md +5 -3
- package/.claude/skills/event-modeling-review/SKILL.md +1 -1
- package/.claude/skills/event-modeling-shared/reference/em-dsl.md +15 -6
- package/.claude/skills/event-modeling-shared/reference/methodology.md +4 -2
- package/.claude-plugin/marketplace.json +2 -2
- package/dist/catalog/sliceReadyValidate.d.ts +5 -0
- package/dist/catalog/sliceReadyValidate.js +3 -2
- package/dist/catalog/sliceReadyValidate.js.map +1 -1
- package/dist/cli/engagement.d.ts +6 -2
- package/dist/cli/engagement.js +17 -6
- package/dist/cli/engagement.js.map +1 -1
- package/dist/cli/findings.d.ts +6 -2
- package/dist/cli/findings.js +7 -3
- package/dist/cli/findings.js.map +1 -1
- package/dist/cli/revise.d.ts +4 -1
- package/dist/cli/revise.js +3 -2
- package/dist/cli/revise.js.map +1 -1
- package/dist/cli/sliceConform.d.ts +16 -6
- package/dist/cli/sliceConform.js +31 -22
- package/dist/cli/sliceConform.js.map +1 -1
- package/dist/cli/upgrade.js +13 -2
- package/dist/cli/upgrade.js.map +1 -1
- package/dist/cli/upgradeReshape.d.ts +11 -0
- package/dist/cli/upgradeReshape.js +77 -11
- package/dist/cli/upgradeReshape.js.map +1 -1
- package/dist/cli.js +14 -6
- package/dist/cli.js.map +1 -1
- package/dist/emit/json.js +1 -1
- package/dist/emit/json.js.map +1 -1
- package/dist/emit/validateJson.d.ts +5 -4
- package/dist/emit/validateJson.js +11 -4
- package/dist/emit/validateJson.js.map +1 -1
- package/dist/mcp/server.js +4 -3
- package/dist/mcp/server.js.map +1 -1
- package/dist/model/edges.d.ts +11 -4
- package/dist/model/edges.js +41 -5
- package/dist/model/edges.js.map +1 -1
- package/dist/model/validate.js +20 -0
- package/dist/model/validate.js.map +1 -1
- package/dist/parser/ast.d.ts +1 -1
- package/dist/parser/parser.js +7 -7
- package/dist/parser/parser.js.map +1 -1
- package/package.json +1 -1
- package/plugin/.claude-plugin/plugin.json +2 -2
- package/plugin/shared/reference/em-dsl.md +15 -6
- package/plugin/shared/reference/methodology.md +4 -2
- package/plugin/skills/conform/SKILL.md +1 -1
- package/plugin/skills/conform/reference/conform.md +2 -1
- package/plugin/skills/design/SKILL.md +1 -1
- package/plugin/skills/discover/SKILL.md +1 -1
- package/plugin/skills/engagement/SKILL.md +1 -1
- package/plugin/skills/event-modeling/SKILL.md +1 -1
- package/plugin/skills/implement/SKILL.md +1 -1
- package/plugin/skills/implement/reference/implement.md +5 -3
- package/plugin/skills/review/SKILL.md +1 -1
|
@@ -364,8 +364,10 @@ drift into **CRUD laid on a timeline**; these rules stop that. Quoted lines are
|
|
|
364
364
|
```
|
|
365
365
|
- **One event, two commands.** When two commands record the same fact, repeat the event bare
|
|
366
366
|
(`event X @Ctx`, same name and context) in the second slice: it inherits the first declaration, no
|
|
367
|
-
marker needed. Declaring different fields is `shared-event-field-mismatch`.
|
|
368
|
-
|
|
367
|
+
marker needed. Declaring different fields is `shared-event-field-mismatch`. Each recording site
|
|
368
|
+
feeds the nearest instance of the reading view at or after it: a `view X again from "E"` draws
|
|
369
|
+
arrows only from the sites of E recorded since the previous instance of X that also reads E (the
|
|
370
|
+
first instance keeps every site at or before it).
|
|
369
371
|
```em
|
|
370
372
|
model "Ordering"
|
|
371
373
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: conform
|
|
3
|
-
em-version: 1.19.
|
|
3
|
+
em-version: 1.19.6
|
|
4
4
|
description: >-
|
|
5
5
|
Use when checking a ratified event model (and its slice docs) for drift against the codebase
|
|
6
6
|
that implements it — advisory only, never a gate, never an unprompted edit — or when walking
|
|
@@ -264,7 +264,8 @@ canonical model or a slice doc unprompted** — walk the report with the user, a
|
|
|
264
264
|
proposals they approve, then re-render and `em validate`.
|
|
265
265
|
|
|
266
266
|
**Also write the findings JSON (MIL-214).** Alongside the report, write
|
|
267
|
-
`conformance/<YYYY-MM-DD>-findings.json`
|
|
267
|
+
`conformance/<YYYY-MM-DD>-findings.json` (write the plain name; `em slice conform` also reads
|
|
268
|
+
`<YYYY-MM-DD>-<name>-findings.json`) — one entry per `### n.` finding, ids matching the
|
|
268
269
|
report's own numbering. Shape (`findingsSchemaVersion: "1.0"`, additive-only, 2-space indent,
|
|
269
270
|
keys sorted, findings sorted by `id`, trailing newline):
|
|
270
271
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: design
|
|
3
|
-
em-version: 1.19.
|
|
3
|
+
em-version: 1.19.6
|
|
4
4
|
description: >-
|
|
5
5
|
Use when structuring a draft event model into swimlanes and the four patterns (State Change,
|
|
6
6
|
State View, Automation, Translation), evaluating a model's structural completeness, or writing
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: discover
|
|
3
|
-
em-version: 1.19.
|
|
3
|
+
em-version: 1.19.6
|
|
4
4
|
description: >-
|
|
5
5
|
Use when starting a brand-new event model from scratch — greenfield discovery: brainstorming
|
|
6
6
|
past-tense events, storyboarding the happy path, finding the commands and read models — or when
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: event-modeling
|
|
3
|
-
em-version: 1.19.
|
|
3
|
+
em-version: 1.19.6
|
|
4
4
|
description: >-
|
|
5
5
|
Use when the user runs `/em:event-modeling` (with or without a phase name), or wants to resume an
|
|
6
6
|
event-modeling session without specifying which part of the process applies. Reads the model's
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: implement
|
|
3
|
-
em-version: 1.19.
|
|
3
|
+
em-version: 1.19.6
|
|
4
4
|
description: >-
|
|
5
5
|
Use when building a single ratified event-modeling slice (status: ready-to-implement) into
|
|
6
6
|
merged, tested code — the one phase where the agent builds rather than facilitates. Gates on
|
|
@@ -43,15 +43,17 @@ every `## Open Questions` checkbox is checked, and no status/version/link incohe
|
|
|
43
43
|
- `fields-completeness/event-field-no-source`: the `assigned` marker contract (MIL-148).
|
|
44
44
|
- `invariants/public-command-without-invariants`: the API-first readiness requirement (`docs/process.md`).
|
|
45
45
|
|
|
46
|
-
A warning whose code is in this list blocks; any other warning never does
|
|
46
|
+
A warning whose code is in this list blocks; any other warning never does — `command-repeated-across-slices`, `timeline-entity-clustered`, `fields-completeness/view-field-no-source`, `open-issue`, `doc-model-*`, `note-binding-*` and the shape lints stay in `diagnostics` and are not blockers. `--strict` promotes advisory rules only.
|
|
47
|
+
|
|
48
|
+
Because of that list, `ready` can be `false` with every `gates` entry `true` (a `both-ends-of-a-flow/*` warning on one of the slice's own elements, say). Don't work it out from `gates`: read **`blockedBy`** (schema `1.5`, GH #377), the codes that flipped `ready`, `[]` exactly when it is `true`, and report those codes with the `false` gates when you hand the slice back.
|
|
47
49
|
|
|
48
50
|
**`ready: false` means stop** — with one named exception: a slice already `status: implemented`
|
|
49
51
|
with `driftSignal: in-sync` or `uncertified` (MIL-214) also reads `ready: false` (its
|
|
50
52
|
`statusReady` gate fails because nothing is newly ratified), and that specific case is
|
|
51
53
|
re-implementation/repair, not a blocker — see §3's third mode before treating it as one. For
|
|
52
54
|
every other `false`, report which `gates`
|
|
53
|
-
entries are `false` (and any `diagnostics` entries concerning this
|
|
54
|
-
back to the humans. Never make the gate pass yourself — checking an open-question box, flipping
|
|
55
|
+
entries are `false` and what `blockedBy` names (and any `diagnostics` entries concerning this
|
|
56
|
+
slice) and hand the slice back to the humans. Never make the gate pass yourself — checking an open-question box, flipping
|
|
55
57
|
`status`, or editing frontmatter are ratification decisions, and ratification happens in a
|
|
56
58
|
facilitated session, not in an implementation branch.
|
|
57
59
|
|