mirai-graph 1.3.0 → 1.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/CHANGELOG.md +38 -0
- package/CITATION.cff +2 -2
- package/README.md +17 -0
- package/examples/executable-technology-course/README.md +16 -0
- package/examples/executable-technology-course/technology.json +99 -0
- package/package.json +41 -40
- package/packages/cli/context-pack.js +0 -0
- package/packages/cli/mirai-graph.js +1 -1
- package/packages/cli/mirai_graph.js +0 -0
- package/packages/cli/project-technology.js +21 -1
- package/packages/cli/readiness-score.js +0 -0
- package/packages/cli/seed-preview.js +0 -0
- package/packages/cli/validate-mirai-graph.js +0 -0
- package/packages/cli/validate-profile-results.js +0 -0
- package/packages/cli/validate-provider-archive.js +165 -0
- package/packages/cli/validate-technology-course.js +81 -0
- package/packages/project-technology/index.js +124 -10
- package/packages/project-technology/technology-course.js +282 -0
- package/releases/1.5.0.md +37 -0
- package/releases/README.md +2 -0
- package/schemas/executable-technology.schema.json +70 -0
- package/schemas/project-technology-target-export.schema.json +1 -0
- package/schemas/technology-course-pack.schema.json +57 -0
- package/standard/project-technology.md +83 -1
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
# Mirai Graph 1.5.0
|
|
2
|
+
|
|
3
|
+
Compatible additive release for existing 1.x consumers. Published to npm under
|
|
4
|
+
`legacy-1`; it does not replace the 2.x `latest` channel or migrate consumers.
|
|
5
|
+
|
|
6
|
+
## Changes
|
|
7
|
+
|
|
8
|
+
- Existing Project Technology connect/refresh can import a bounded provider
|
|
9
|
+
export without Git when an authenticated distributor supplies its exact
|
|
10
|
+
export digest, graph identity, revision and forward ancestry proof.
|
|
11
|
+
- Read-only source verification binds that proof to the accepted target and
|
|
12
|
+
real Git revision before packaging. Caller-supplied trust is not inferred
|
|
13
|
+
from an export's own claims and never grants permission to perform work.
|
|
14
|
+
- Folder inventory follows only explicitly declared graph and raw-source paths,
|
|
15
|
+
detects stale content and rejects unsafe or missing sources.
|
|
16
|
+
- CLI archive trust can be passed through stdin without a temporary trust file.
|
|
17
|
+
|
|
18
|
+
## Compatibility and safety
|
|
19
|
+
|
|
20
|
+
Existing Git provider operations, complete target and execution contracts,
|
|
21
|
+
transactional rollback and fail-closed behavior remain in force. No new profile,
|
|
22
|
+
registry, daemon or schema family is introduced. The graph manifest remains
|
|
23
|
+
2.0.0 and the Project Technology activation contract remains 1.0.0.
|
|
24
|
+
|
|
25
|
+
Archive metadata must come from an independently authenticated release; this
|
|
26
|
+
package does not establish a distributor's trust or copy private source content.
|
|
27
|
+
|
|
28
|
+
## Verification
|
|
29
|
+
|
|
30
|
+
`npm run release:check` runs the current suite, including 39 existing Project
|
|
31
|
+
Technology checks and 71 archive/source-proof checks. The archive cases cover
|
|
32
|
+
no-Git import, exact replay, forward refresh, downgrade, tamper, graph conflict,
|
|
33
|
+
missing trust, source inventory and read-only behavior.
|
|
34
|
+
|
|
35
|
+
Local validation uses macOS ARM64 with Node 22.23.2. Federation's native
|
|
36
|
+
Windows/macOS/Linux complete installation matrix is a separate acceptance gate;
|
|
37
|
+
this release does not claim that matrix or a Federation release has passed.
|
package/releases/README.md
CHANGED
|
@@ -15,6 +15,8 @@ Release notes must separate:
|
|
|
15
15
|
|
|
16
16
|
## Release Notes
|
|
17
17
|
|
|
18
|
+
- [v1.5.0](1.5.0.md) - compatible 1.x authenticated archive providers and
|
|
19
|
+
declared-source inventory without Git (`legacy-1`, not npm `latest`).
|
|
18
20
|
- [v1.2.0](1.2.0.md) - portable task-boundary project continuity in Project
|
|
19
21
|
Technology.
|
|
20
22
|
- [v1.1.0](1.1.0.md) - universal sequential context traversal and usage
|
|
@@ -0,0 +1,70 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://json-schema.org/draft/2020-12/schema",
|
|
3
|
+
"$id": "https://mirai-graph.org/schemas/executable-technology.schema.json",
|
|
4
|
+
"title": "Mirai Graph Executable Technology",
|
|
5
|
+
"type": "object",
|
|
6
|
+
"additionalProperties": false,
|
|
7
|
+
"required": ["schema_version", "id", "title", "owner", "outcome", "lifecycle", "version", "source_refs", "operations", "scenarios"],
|
|
8
|
+
"properties": {
|
|
9
|
+
"schema_version": { "const": "1.0.0" },
|
|
10
|
+
"id": { "$ref": "#/$defs/id" },
|
|
11
|
+
"title": { "$ref": "#/$defs/text" },
|
|
12
|
+
"owner": { "$ref": "#/$defs/id" },
|
|
13
|
+
"outcome": { "$ref": "#/$defs/text" },
|
|
14
|
+
"lifecycle": { "enum": ["reviewed", "accepted", "active"] },
|
|
15
|
+
"version": { "$ref": "#/$defs/text" },
|
|
16
|
+
"source_refs": { "$ref": "#/$defs/nonEmptyIds" },
|
|
17
|
+
"projection_refs": { "$ref": "#/$defs/ids" },
|
|
18
|
+
"operations": {
|
|
19
|
+
"type": "array",
|
|
20
|
+
"minItems": 1,
|
|
21
|
+
"items": { "$ref": "#/$defs/operation" }
|
|
22
|
+
},
|
|
23
|
+
"scenarios": {
|
|
24
|
+
"type": "array",
|
|
25
|
+
"minItems": 1,
|
|
26
|
+
"items": { "$ref": "#/$defs/scenario" }
|
|
27
|
+
}
|
|
28
|
+
},
|
|
29
|
+
"$defs": {
|
|
30
|
+
"id": { "type": "string", "pattern": "^[A-Za-z0-9][A-Za-z0-9._:/@?=+*\\-]{1,255}$" },
|
|
31
|
+
"text": { "type": "string", "minLength": 1 },
|
|
32
|
+
"ids": { "type": "array", "uniqueItems": true, "items": { "$ref": "#/$defs/id" } },
|
|
33
|
+
"nonEmptyIds": { "type": "array", "minItems": 1, "uniqueItems": true, "items": { "$ref": "#/$defs/id" } },
|
|
34
|
+
"operation": {
|
|
35
|
+
"type": "object",
|
|
36
|
+
"additionalProperties": false,
|
|
37
|
+
"required": ["id", "title", "summary", "owner", "capability_ref", "output_refs", "check_refs", "source_refs"],
|
|
38
|
+
"properties": {
|
|
39
|
+
"id": { "$ref": "#/$defs/id" },
|
|
40
|
+
"title": { "$ref": "#/$defs/text" },
|
|
41
|
+
"summary": { "$ref": "#/$defs/text" },
|
|
42
|
+
"owner": { "$ref": "#/$defs/id" },
|
|
43
|
+
"capability_ref": { "$ref": "#/$defs/id" },
|
|
44
|
+
"prerequisites": { "$ref": "#/$defs/ids" },
|
|
45
|
+
"input_refs": { "$ref": "#/$defs/ids" },
|
|
46
|
+
"output_refs": { "$ref": "#/$defs/nonEmptyIds" },
|
|
47
|
+
"check_refs": { "$ref": "#/$defs/nonEmptyIds" },
|
|
48
|
+
"stop_condition_refs": { "$ref": "#/$defs/ids" },
|
|
49
|
+
"rollback_refs": { "$ref": "#/$defs/ids" },
|
|
50
|
+
"source_refs": { "$ref": "#/$defs/nonEmptyIds" },
|
|
51
|
+
"instructional_refs": { "$ref": "#/$defs/ids" },
|
|
52
|
+
"applicability": { "type": "array", "uniqueItems": true, "items": { "$ref": "#/$defs/text" } },
|
|
53
|
+
"negative_boundaries": { "type": "array", "uniqueItems": true, "items": { "$ref": "#/$defs/text" } }
|
|
54
|
+
}
|
|
55
|
+
},
|
|
56
|
+
"scenario": {
|
|
57
|
+
"type": "object",
|
|
58
|
+
"additionalProperties": false,
|
|
59
|
+
"required": ["id", "title", "outcome", "operation_ids"],
|
|
60
|
+
"properties": {
|
|
61
|
+
"id": { "$ref": "#/$defs/id" },
|
|
62
|
+
"title": { "$ref": "#/$defs/text" },
|
|
63
|
+
"outcome": { "$ref": "#/$defs/text" },
|
|
64
|
+
"operation_ids": { "$ref": "#/$defs/nonEmptyIds" },
|
|
65
|
+
"required_inputs": { "$ref": "#/$defs/ids" },
|
|
66
|
+
"audience": { "type": "array", "uniqueItems": true, "items": { "$ref": "#/$defs/text" } }
|
|
67
|
+
}
|
|
68
|
+
}
|
|
69
|
+
}
|
|
70
|
+
}
|
|
@@ -15,6 +15,7 @@
|
|
|
15
15
|
"target_id": { "type": "string", "minLength": 2 },
|
|
16
16
|
"semantic_digest": { "type": "string", "pattern": "^sha256:[0-9a-f]{64}$" },
|
|
17
17
|
"provider_revision": { "type": "string", "pattern": "^[0-9a-f]{40}$" },
|
|
18
|
+
"provider_graph_id": { "type": "string", "minLength": 2, "maxLength": 256, "pattern": "^[A-Za-z0-9][A-Za-z0-9._:/@?=+*-]+$" },
|
|
18
19
|
"decision_refs": { "$ref": "#/$defs/nonEmptyRefs" },
|
|
19
20
|
"goal_binding": {
|
|
20
21
|
"type": "object", "additionalProperties": false,
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://json-schema.org/draft/2020-12/schema",
|
|
3
|
+
"$id": "https://mirai-graph.org/schemas/technology-course-pack.schema.json",
|
|
4
|
+
"title": "Mirai Graph Technology Course Pack",
|
|
5
|
+
"type": "object",
|
|
6
|
+
"additionalProperties": false,
|
|
7
|
+
"required": ["schema_version", "technology_id", "technology_title", "technology_outcome", "technology_version", "technology_digest", "audience", "scenario_ids", "source_refs", "source_revisions", "scenarios", "sections", "exercises", "checks", "omissions", "limitations", "course_pack_digest"],
|
|
8
|
+
"properties": {
|
|
9
|
+
"schema_version": { "const": "1.0.0" },
|
|
10
|
+
"technology_id": { "$ref": "#/$defs/id" },
|
|
11
|
+
"technology_title": { "type": "string", "minLength": 1 },
|
|
12
|
+
"technology_outcome": { "type": "string", "minLength": 1 },
|
|
13
|
+
"technology_version": { "type": "string", "minLength": 1 },
|
|
14
|
+
"technology_digest": { "$ref": "#/$defs/digest" },
|
|
15
|
+
"audience": { "$ref": "#/$defs/id" },
|
|
16
|
+
"scenario_ids": { "$ref": "#/$defs/nonEmptyIds" },
|
|
17
|
+
"source_refs": { "$ref": "#/$defs/nonEmptyIds" },
|
|
18
|
+
"source_revisions": { "type": "object", "additionalProperties": { "type": "string", "minLength": 1 } },
|
|
19
|
+
"scenarios": { "type": "array", "minItems": 1, "items": { "type": "object" } },
|
|
20
|
+
"sections": {
|
|
21
|
+
"type": "array",
|
|
22
|
+
"minItems": 1,
|
|
23
|
+
"items": {
|
|
24
|
+
"type": "object",
|
|
25
|
+
"additionalProperties": false,
|
|
26
|
+
"required": ["order", "technology_node_id", "title", "summary", "owner", "capability_ref", "prerequisite_ids", "input_refs", "output_refs", "check_refs", "stop_condition_refs", "rollback_refs", "source_refs", "instructional_refs"],
|
|
27
|
+
"properties": {
|
|
28
|
+
"order": { "type": "integer", "minimum": 1 },
|
|
29
|
+
"technology_node_id": { "$ref": "#/$defs/id" },
|
|
30
|
+
"title": { "type": "string", "minLength": 1 },
|
|
31
|
+
"summary": { "type": "string", "minLength": 1 },
|
|
32
|
+
"owner": { "$ref": "#/$defs/id" },
|
|
33
|
+
"capability_ref": { "$ref": "#/$defs/id" },
|
|
34
|
+
"prerequisite_ids": { "$ref": "#/$defs/ids" },
|
|
35
|
+
"input_refs": { "$ref": "#/$defs/ids" },
|
|
36
|
+
"output_refs": { "$ref": "#/$defs/nonEmptyIds" },
|
|
37
|
+
"check_refs": { "$ref": "#/$defs/nonEmptyIds" },
|
|
38
|
+
"stop_condition_refs": { "$ref": "#/$defs/ids" },
|
|
39
|
+
"rollback_refs": { "$ref": "#/$defs/ids" },
|
|
40
|
+
"source_refs": { "$ref": "#/$defs/nonEmptyIds" },
|
|
41
|
+
"instructional_refs": { "$ref": "#/$defs/ids" }
|
|
42
|
+
}
|
|
43
|
+
}
|
|
44
|
+
},
|
|
45
|
+
"exercises": { "type": "array" },
|
|
46
|
+
"checks": { "$ref": "#/$defs/nonEmptyIds" },
|
|
47
|
+
"omissions": { "type": "array" },
|
|
48
|
+
"limitations": { "type": "array" },
|
|
49
|
+
"course_pack_digest": { "$ref": "#/$defs/digest" }
|
|
50
|
+
},
|
|
51
|
+
"$defs": {
|
|
52
|
+
"id": { "type": "string", "pattern": "^[A-Za-z0-9][A-Za-z0-9._:/@?=+*\\-]{1,255}$" },
|
|
53
|
+
"digest": { "type": "string", "pattern": "^sha256:[a-f0-9]{64}$" },
|
|
54
|
+
"ids": { "type": "array", "uniqueItems": true, "items": { "$ref": "#/$defs/id" } },
|
|
55
|
+
"nonEmptyIds": { "type": "array", "minItems": 1, "uniqueItems": true, "items": { "$ref": "#/$defs/id" } }
|
|
56
|
+
}
|
|
57
|
+
}
|
|
@@ -1,12 +1,65 @@
|
|
|
1
1
|
# Project Technology
|
|
2
2
|
|
|
3
|
-
Status: 1.
|
|
3
|
+
Status: 1.4 stable standard; activation contract remains 1.0.0
|
|
4
4
|
|
|
5
5
|
Project Technology is the shared executable mechanism of Mirai Graph. It is
|
|
6
6
|
not a profile, a second graph or a source of domain methodology.
|
|
7
7
|
|
|
8
8
|
## One Mechanism, Different Graphs
|
|
9
9
|
|
|
10
|
+
### Archived providers (unreleased compatibility extension)
|
|
11
|
+
|
|
12
|
+
The normal source provider path continues to verify Git HEAD and ancestry.
|
|
13
|
+
For an immutable distribution, `connect` also accepts `providerArchive` in the
|
|
14
|
+
JavaScript options, or `--provider-archive-trust <file>` in the CLI (use `-`
|
|
15
|
+
to read that bounded JSON from stdin without creating a temporary file):
|
|
16
|
+
|
|
17
|
+
```json
|
|
18
|
+
{
|
|
19
|
+
"exportSha256": "<SHA-256 of the exact bounded export bytes>",
|
|
20
|
+
"graphId": "example.provider",
|
|
21
|
+
"providerRevision": "<exact 40-character source revision>",
|
|
22
|
+
"ancestorRevisions": ["<previous supported revision, proven during release build>"]
|
|
23
|
+
}
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
This is a **consumer trust input**, not provider self-authentication. The caller
|
|
27
|
+
must derive it from an authenticated release lock/manifest after checking its
|
|
28
|
+
integrity and issuer. Never calculate a hash from an untrusted download and
|
|
29
|
+
call that authentication. Mirai does not discover, download or trust adjacent
|
|
30
|
+
metadata automatically. Packaging must verify the export against the accepted
|
|
31
|
+
source target and the declared source revision before publishing its digest.
|
|
32
|
+
Ancestor entries must be proven by the source Git history during that build;
|
|
33
|
+
they are not inferred from version numbers, dates or commit hash ordering.
|
|
34
|
+
|
|
35
|
+
The existing `technology verify <repository> --source <bounded-export>` and
|
|
36
|
+
`verifyProviderExport(repository, options)` provide a read-only source-side
|
|
37
|
+
proof for packaging. They require a revision-bound enabled manifest, exact HEAD,
|
|
38
|
+
accepted target and matching execution contract, and return the anchor with at
|
|
39
|
+
most 4096 proven ancestors. A packaging caller must then authenticate the release
|
|
40
|
+
metadata containing this anchor. This proof is not permission to execute a
|
|
41
|
+
significant task; requesting significant work through it is blocked.
|
|
42
|
+
|
|
43
|
+
Exports produced by `provide` now include `provider_graph_id`. Old Git-backed
|
|
44
|
+
exports remain readable; archive import requires the graph identity. `connect`
|
|
45
|
+
uses the same full accepted execution contract validation and atomic import.
|
|
46
|
+
`--refresh-binding` still requires the same target and semantic/architecture
|
|
47
|
+
contract; a changed revision must explicitly descend from the current binding
|
|
48
|
+
in the authenticated release metadata. A wrong or incomplete anchor fails,
|
|
49
|
+
even when a working Git checkout happens to be available. The caller cannot
|
|
50
|
+
use archive trust to authorize work, change owners, expand scope or bypass
|
|
51
|
+
acceptance. `provide` continues to require the canonical Git source; archive
|
|
52
|
+
consumers import its immutable output, never regenerate acceptance from copies.
|
|
53
|
+
|
|
54
|
+
Status/verify use the hash-bound local import and remain read-only. Without a
|
|
55
|
+
Git repository, inventory reads only the manifest and explicitly declared graph
|
|
56
|
+
and raw-source paths, with a bounded traversal. Missing, unsafe or unsupported
|
|
57
|
+
declared paths block sync before writes. Symlinks and secret/excluded paths are
|
|
58
|
+
not imported. Ordinary folders use content digests and a null inventory revision,
|
|
59
|
+
never a fabricated Git revision. If Git metadata exists but Git is unavailable,
|
|
60
|
+
inventory fails closed instead of silently treating a checkout as an archive.
|
|
61
|
+
Raw-source access and release authenticity remain separate responsibilities.
|
|
62
|
+
|
|
10
63
|
The root `graph.json` declares the repository scope and profiles. The same
|
|
11
64
|
Project Technology operations therefore work for:
|
|
12
65
|
|
|
@@ -19,6 +72,35 @@ Each graph keeps its own objects and relations. Project Technology only
|
|
|
19
72
|
standardizes safe inventory, task context, accepted-target binding, freshness
|
|
20
73
|
and verification.
|
|
21
74
|
|
|
75
|
+
## Executable Technologies And Course Projections
|
|
76
|
+
|
|
77
|
+
An executable technology is an accepted graph of reusable operations and
|
|
78
|
+
user-facing scenarios. It is suitable for a long method that has both an
|
|
79
|
+
end-to-end path and independently useful parts. Each operation binds its owner,
|
|
80
|
+
capability, prerequisites, inputs, outputs, checks, stop conditions, rollback
|
|
81
|
+
and exact raw source references.
|
|
82
|
+
|
|
83
|
+
A scenario names an outcome and selects the operations needed to reach it.
|
|
84
|
+
Project Technology calculates prerequisite closure, so a course or executor
|
|
85
|
+
cannot silently omit a required safety step.
|
|
86
|
+
|
|
87
|
+
```bash
|
|
88
|
+
mirai-graph technology course compile . --technology graph/specs/technology.json
|
|
89
|
+
mirai-graph technology course compile . --technology graph/specs/technology.json --scenario scenario.recovery
|
|
90
|
+
mirai-graph technology course verify . --course-pack course-pack.json
|
|
91
|
+
mirai-graph technology course reconcile . --course-pack course-pack.json --projection edited-course.json
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
The JavaScript API exposes `compileTechnologyCourse`,
|
|
95
|
+
`verifyTechnologyCourse` and `reconcileTechnologyCourse`.
|
|
96
|
+
|
|
97
|
+
A Course Pack is hash-bound to the normalized technology, chosen scenarios,
|
|
98
|
+
sources and revisions. It may be rendered into a document, learning system or
|
|
99
|
+
documentation site. It remains a projection: editorial changes may be routed
|
|
100
|
+
to the documentation owner, while changed prerequisites, owners, checks, stop
|
|
101
|
+
conditions, rollback or scope become semantic proposals. Reconciliation never
|
|
102
|
+
writes them into the accepted technology automatically.
|
|
103
|
+
|
|
22
104
|
## Immutable Artifact Releases
|
|
23
105
|
|
|
24
106
|
Project Technology can preserve versioned file bundles without turning their
|