sysprom 1.18.0 → 1.19.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 +53 -12
- package/dist/src/endpoint-types.js +11 -3
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -82,7 +82,7 @@ sysprom query node D1
|
|
|
82
82
|
sysprom query rels --from D1
|
|
83
83
|
sysprom query trace I1
|
|
84
84
|
sysprom query timeline
|
|
85
|
-
sysprom query state-at
|
|
85
|
+
sysprom query state-at <ISO-timestamp>
|
|
86
86
|
|
|
87
87
|
# Add nodes (ID auto-generated from type prefix if --id omitted)
|
|
88
88
|
|
|
@@ -116,7 +116,7 @@ All commands auto-detect the document — they search the current directory for
|
|
|
116
116
|
|
|
117
117
|
## MCP Server
|
|
118
118
|
|
|
119
|
-
SysProM includes an MCP (Model Context Protocol) server exposing
|
|
119
|
+
SysProM includes an MCP (Model Context Protocol) server exposing tools over stdio transport. Any MCP-compatible agent — Cursor, Windsurf, VS Code Copilot, Cline, or custom clients — can use it.
|
|
120
120
|
|
|
121
121
|
### Configuration
|
|
122
122
|
|
|
@@ -245,6 +245,47 @@ if (node.is(thing)) {
|
|
|
245
245
|
|
|
246
246
|
SysProM models systems as directed graphs across abstraction layers — intent, concept, capability, structure, and realisation — with explicit decisions, changes, and invariants. It is domain-agnostic, format-agnostic, and recursively composable.
|
|
247
247
|
|
|
248
|
+
## System Provenance Profile
|
|
249
|
+
|
|
250
|
+
For product repositories, use SysProM to model the specification, design, and implementation of the system being built.
|
|
251
|
+
|
|
252
|
+
Recommended node usage:
|
|
253
|
+
|
|
254
|
+
- `intent`: user outcomes, business goals, and product promises
|
|
255
|
+
- `concept`: domain concepts, behavioural boundaries, and system rules
|
|
256
|
+
- `capability`: user-visible or externally meaningful system behaviours
|
|
257
|
+
- `element`: architectural components, services, stores, queues, and UI surfaces
|
|
258
|
+
- `realisation`: implementation units such as packages, modules, handlers, schemas, and jobs
|
|
259
|
+
- `protocol`: workflows and lifecycle paths such as review, publish, sync, or ingestion flows
|
|
260
|
+
- `artefact`: API contracts, documents, prompts, tests, migrations, and generated outputs
|
|
261
|
+
- `decision`: selected trade-offs and architectural choices
|
|
262
|
+
- `change`: implementation slices or delivery units
|
|
263
|
+
- `role`: human or system actors
|
|
264
|
+
- `view`: curated slices such as specification, architecture, implementation, and operations
|
|
265
|
+
|
|
266
|
+
Recommended trace chain:
|
|
267
|
+
|
|
268
|
+
```text
|
|
269
|
+
intent -> concept -> capability -> element -> realisation -> artefact
|
|
270
|
+
```
|
|
271
|
+
|
|
272
|
+
Recommended relationship usage:
|
|
273
|
+
|
|
274
|
+
- `refines`: tighten intent into concepts and concepts into capabilities
|
|
275
|
+
- `part_of`: decompose concepts, protocols, capabilities, and architecture structures
|
|
276
|
+
- `realises`: connect design structures to implementation structures
|
|
277
|
+
- `produces`: connect capabilities or stages to the artefacts they generate
|
|
278
|
+
- `performs`: connect roles to capabilities, stages, protocols, and operational concepts
|
|
279
|
+
- `governed_by` / `constrained_by`: express rules, policies, and invariants on design and implementation
|
|
280
|
+
- `implements` / `modifies`: connect delivery changes to the nodes they implement or alter
|
|
281
|
+
- `affects` + `must_preserve`: connect decisions to impacted areas and their protected invariants
|
|
282
|
+
|
|
283
|
+
Recommended implementation provenance:
|
|
284
|
+
|
|
285
|
+
- use `external_references` on `realisation` nodes to point to code paths, packages, handlers, or schemas
|
|
286
|
+
- use `external_references` on `artefact` nodes to point to API definitions, test files, migrations, docs, PRs, and generated outputs
|
|
287
|
+
- use `status`, `scope`, and decision/change links so the graph can answer both “what is the design?” and “what has actually been built?”
|
|
288
|
+
|
|
248
289
|
## How SysProM Compares
|
|
249
290
|
|
|
250
291
|
<table>
|
|
@@ -363,7 +404,7 @@ sysprom md2json --input ./.SysProM --output .SysProM.json
|
|
|
363
404
|
|
|
364
405
|
## Claude Code Plugin
|
|
365
406
|
|
|
366
|
-
SysProM is available as a Claude Code plugin with
|
|
407
|
+
SysProM is available as a Claude Code plugin with skills for managing provenance documents. The plugin is defined in `.claude-plugin/marketplace.json` with skills in `.claude/skills/`.
|
|
367
408
|
|
|
368
409
|
### Install from Marketplace
|
|
369
410
|
|
|
@@ -383,25 +424,25 @@ When working on the SysProM repo itself, skills in `.claude/skills/` are auto-di
|
|
|
383
424
|
|
|
384
425
|
### Skills by Category
|
|
385
426
|
|
|
386
|
-
**Node Creation
|
|
427
|
+
**Node Creation**
|
|
387
428
|
|
|
388
429
|
- `add-decision` — Create decision nodes with context, options, rationale, and invariant links
|
|
389
430
|
- `add-change` — Create change nodes with scope, operations, and task tracking
|
|
390
431
|
- `add-invariant` — Create invariant nodes representing system rules and constraints
|
|
391
432
|
- `add-node` — Generic node creation for any SysProM type
|
|
392
433
|
|
|
393
|
-
**Node Modification
|
|
434
|
+
**Node Modification**
|
|
394
435
|
|
|
395
436
|
- `update-node` — Modify node fields, status, lifecycle, context, or rationale
|
|
396
437
|
- `remove-node` — Delete nodes with safety flags (hard delete, recursive, repair)
|
|
397
438
|
- `rename-node` — Rename node IDs across all references
|
|
398
439
|
|
|
399
|
-
**Relationships
|
|
440
|
+
**Relationships**
|
|
400
441
|
|
|
401
442
|
- `add-relationship` — Create relationships between nodes with specific types
|
|
402
443
|
- `remove-relationship` — Delete relationships
|
|
403
444
|
|
|
404
|
-
**Query & Analysis
|
|
445
|
+
**Query & Analysis**
|
|
405
446
|
|
|
406
447
|
- `query-nodes` — Search nodes by type, status, text, or ID
|
|
407
448
|
- `query-relationships` — Query relationships by source, target, or type
|
|
@@ -409,31 +450,31 @@ When working on the SysProM repo itself, skills in `.claude/skills/` are auto-di
|
|
|
409
450
|
- `check-document` — Validate document structure and report issues
|
|
410
451
|
- `stats` — Show document statistics and composition metrics
|
|
411
452
|
|
|
412
|
-
**Visualisation
|
|
453
|
+
**Visualisation**
|
|
413
454
|
|
|
414
455
|
- `graph` — Generate Mermaid or DOT graphs with filtering
|
|
415
456
|
|
|
416
|
-
**Format Conversion
|
|
457
|
+
**Format Conversion**
|
|
417
458
|
|
|
418
459
|
- `init-document` — Create new SysProM documents with metadata
|
|
419
460
|
- `json-to-markdown` — Convert JSON to Markdown format
|
|
420
461
|
- `markdown-to-json` — Convert Markdown to JSON format
|
|
421
462
|
- `sync-formats` — Bidirectional sync between JSON and Markdown
|
|
422
463
|
|
|
423
|
-
**Spec-Kit Integration
|
|
464
|
+
**Spec-Kit Integration**
|
|
424
465
|
|
|
425
466
|
- `speckit-import` — Import Spec-Kit features as SysProM nodes
|
|
426
467
|
- `speckit-export` — Export SysProM nodes to Spec-Kit format
|
|
427
468
|
- `speckit-sync` — Bidirectional sync with Spec-Kit specifications
|
|
428
469
|
- `speckit-diff` — Show differences between SysProM and Spec-Kit
|
|
429
470
|
|
|
430
|
-
**Task Management
|
|
471
|
+
**Task Management**
|
|
431
472
|
|
|
432
473
|
- `task-list` — List tasks in a change node with progress
|
|
433
474
|
- `task-add` — Add tasks to a change
|
|
434
475
|
- `task-mark-done` — Mark tasks as complete
|
|
435
476
|
|
|
436
|
-
**Plan Management
|
|
477
|
+
**Plan Management**
|
|
437
478
|
|
|
438
479
|
- `plan-init` — Initialise plans with phases and gates
|
|
439
480
|
- `plan-status` — Show plan progress and phase gates
|
|
@@ -161,7 +161,14 @@ export const RELATIONSHIP_ENDPOINT_TYPES = {
|
|
|
161
161
|
// Performs — process enactment
|
|
162
162
|
performs: {
|
|
163
163
|
from: ["stage", "role"],
|
|
164
|
-
to: [
|
|
164
|
+
to: [
|
|
165
|
+
"capability",
|
|
166
|
+
"artefact",
|
|
167
|
+
"artefact_flow",
|
|
168
|
+
"stage",
|
|
169
|
+
"concept",
|
|
170
|
+
"protocol",
|
|
171
|
+
],
|
|
165
172
|
},
|
|
166
173
|
// Precedes — temporal ordering
|
|
167
174
|
precedes: {
|
|
@@ -185,6 +192,7 @@ export const RELATIONSHIP_ENDPOINT_TYPES = {
|
|
|
185
192
|
"stage",
|
|
186
193
|
"policy",
|
|
187
194
|
"principle",
|
|
195
|
+
"protocol",
|
|
188
196
|
"role",
|
|
189
197
|
"gate",
|
|
190
198
|
"mode",
|
|
@@ -260,7 +268,7 @@ export const RELATIONSHIP_ENDPOINT_TYPES = {
|
|
|
260
268
|
},
|
|
261
269
|
// Applies to — applicability and scope
|
|
262
270
|
applies_to: {
|
|
263
|
-
from: ["policy", "principle", "mode", "protocol"],
|
|
271
|
+
from: ["policy", "principle", "mode", "protocol", "invariant"],
|
|
264
272
|
to: [
|
|
265
273
|
"intent",
|
|
266
274
|
"concept",
|
|
@@ -275,7 +283,7 @@ export const RELATIONSHIP_ENDPOINT_TYPES = {
|
|
|
275
283
|
},
|
|
276
284
|
// Produces — generation
|
|
277
285
|
produces: {
|
|
278
|
-
from: ["stage", "artefact_flow", "realisation", "concept"],
|
|
286
|
+
from: ["stage", "artefact_flow", "realisation", "concept", "capability"],
|
|
279
287
|
to: ["artefact", "concept"],
|
|
280
288
|
},
|
|
281
289
|
// Consumes — usage
|