@mriekki/project-forge 4.13.2 → 4.13.4
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/components.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"schemaVersion": 2,
|
|
3
3
|
"package": "@mriekki/project-forge",
|
|
4
|
-
"version": "4.13.
|
|
4
|
+
"version": "4.13.4",
|
|
5
5
|
"defaultProfile": "greenfield-project",
|
|
6
6
|
"profiles": {
|
|
7
7
|
"greenfield-project": {
|
|
@@ -13,7 +13,7 @@
|
|
|
13
13
|
},
|
|
14
14
|
"components": {
|
|
15
15
|
"core": {
|
|
16
|
-
"revision": "
|
|
16
|
+
"revision": "b51cb62bcc9630748168c9fd1900c6109cafb587",
|
|
17
17
|
"version": "4.0.0",
|
|
18
18
|
"distribution": "greenfield-workspace",
|
|
19
19
|
"descriptor": "assets/core/distribution.json",
|
|
@@ -1,10 +1,10 @@
|
|
|
1
1
|
{
|
|
2
2
|
"schemaVersion": 2,
|
|
3
3
|
"package": "@mriekki/project-forge",
|
|
4
|
-
"version": "4.13.
|
|
4
|
+
"version": "4.13.4",
|
|
5
5
|
"components": {
|
|
6
6
|
"core": {
|
|
7
|
-
"revision": "
|
|
7
|
+
"revision": "b51cb62bcc9630748168c9fd1900c6109cafb587",
|
|
8
8
|
"version": "4.0.0",
|
|
9
9
|
"distribution": "greenfield-workspace",
|
|
10
10
|
"files": [
|
|
@@ -71,12 +71,12 @@
|
|
|
71
71
|
{
|
|
72
72
|
"source": "core/skills/export-requirements/SKILL.md",
|
|
73
73
|
"destination": ".github/skills/export-requirements/SKILL.md",
|
|
74
|
-
"sha256": "
|
|
74
|
+
"sha256": "05d2ce830b2924f3508641f6bfa056f577862f27d236526f5a217a790d1ad490"
|
|
75
75
|
},
|
|
76
76
|
{
|
|
77
77
|
"source": "core/skills/replatform/SKILL.md",
|
|
78
78
|
"destination": ".github/skills/replatform/SKILL.md",
|
|
79
|
-
"sha256": "
|
|
79
|
+
"sha256": "c43896b2b8ec92467769c32bf39de1e9d4f1090cef42005e22126cb2df88af59"
|
|
80
80
|
},
|
|
81
81
|
{
|
|
82
82
|
"source": "core/skills/progress/SKILL.md",
|
|
@@ -38,16 +38,19 @@ https://raw.githubusercontent.com/mriekki/project-forge-platform/main/chatgpt/cu
|
|
|
38
38
|
|
|
39
39
|
Use the exact `generation.bootstrap.revision` from that descriptor as the Bootstrap contract authority for this export session. Do not use a remembered schema, an older generated example, or this skill's prose as a substitute for the current Bootstrap-owned portable-requirements contract.
|
|
40
40
|
|
|
41
|
-
|
|
41
|
+
The stable descriptor must provide `generation.bootstrap.portableRequirements` with public immutable locators for the canonical schema and validator. Require all of the following before continuing:
|
|
42
42
|
|
|
43
|
-
|
|
44
|
-
schemas/project-requirements.schema.json
|
|
45
|
-
tools/project_requirements.py
|
|
46
|
-
|
|
43
|
+
- `portableRequirements.bootstrapRevision` exactly equals `generation.bootstrap.revision`;
|
|
44
|
+
- `portableRequirements.schema.path` equals `schemas/project-requirements.schema.json`;
|
|
45
|
+
- `portableRequirements.validator.path` equals `tools/project_requirements.py`;
|
|
46
|
+
- both locator URLs resolve from an immutable public Platform commit rather than a mutable branch;
|
|
47
|
+
- both advertised SHA-256 values match the retrieved bytes.
|
|
48
|
+
|
|
49
|
+
Fetch and inspect the schema and validator through those public locators. Do not infer or expose the private foundational repository from the bare Bootstrap revision, and do not substitute similarly named files discovered through code search.
|
|
47
50
|
|
|
48
|
-
Bootstrap owns the schema/validator. Core owns this orchestration. Do not copy the Bootstrap schema into Core, invent a parallel validator, or infer a compatibility transform for a shape that the canonical validator rejects.
|
|
51
|
+
Bootstrap owns the schema/validator. Platform publishes the reviewed public immutable mirrors/locators. Core owns this orchestration. Do not copy the Bootstrap schema into Core, invent a parallel validator, or infer a compatibility transform for a shape that the canonical validator rejects.
|
|
49
52
|
|
|
50
|
-
If the stable descriptor, exact Bootstrap revision, canonical schema,
|
|
53
|
+
If the stable descriptor, exact Bootstrap revision, public locator metadata, canonical schema, canonical validator, or digest verification cannot be resolved and inspected, stop with:
|
|
51
54
|
|
|
52
55
|
```text
|
|
53
56
|
PORTABLE REQUIREMENTS VALIDATION REQUIRED
|
|
@@ -131,13 +134,13 @@ Do not export as portable requirements:
|
|
|
131
134
|
|
|
132
135
|
Default `/export-requirements` writes or refreshes `PROJECT_REQUIREMENTS.json` with `state: "review"` and exact source repository/commit provenance, using the current Bootstrap schema as the structural contract.
|
|
133
136
|
|
|
134
|
-
Before presenting any approval question, validate that exact file with the canonical Bootstrap validator from the exact revision resolved during preflight. The equivalent canonical invocation is:
|
|
137
|
+
Before presenting any approval question, validate that exact file with the canonical Bootstrap validator retrieved and digest-verified from the public locator for the exact revision resolved during preflight. The equivalent canonical source-layout invocation is:
|
|
135
138
|
|
|
136
139
|
```text
|
|
137
140
|
python tools/project_requirements.py <path-to-PROJECT_REQUIREMENTS.json>
|
|
138
141
|
```
|
|
139
142
|
|
|
140
|
-
The actual
|
|
143
|
+
The actual local path may differ by host, but the validator bytes and Bootstrap revision must be the same canonical ones resolved and verified during preflight.
|
|
141
144
|
|
|
142
145
|
If validation fails:
|
|
143
146
|
|
|
@@ -22,7 +22,11 @@ PROJECT_REQUIREMENTS.json
|
|
|
22
22
|
|
|
23
23
|
The file must be `state: "approved"`. Do not accept alternate/legacy requirements-export filenames or infer approval from file existence.
|
|
24
24
|
|
|
25
|
-
Before consuming the export, validate it with the canonical Bootstrap portable-requirements validator from the
|
|
25
|
+
Before consuming the export, validate it with the canonical Bootstrap portable-requirements validator resolved from the current stable Project Forge descriptor and its `generation.bootstrap.portableRequirements` metadata. Require `portableRequirements.bootstrapRevision` to equal `generation.bootstrap.revision`, fetch the canonical validator from the advertised immutable public locator, verify its advertised SHA-256, and validate the export with that exact validator using `--require-approved`.
|
|
26
|
+
|
|
27
|
+
Do not infer or expose the private foundational repository from the Bootstrap revision, and do not substitute similarly named files discovered through code search. If the public locator metadata, canonical validator, digest verification, or exact Bootstrap revision cannot be resolved, stop with `PORTABLE REQUIREMENTS VALIDATION REQUIRED`.
|
|
28
|
+
|
|
29
|
+
If canonical validation fails, stop and route back through `/export-requirements`; do not normalize, translate, alias, or repair the input inside `/replatform`.
|
|
26
30
|
|
|
27
31
|
A previously human-approved file that does not validate against the canonical portable contract is not valid replatform input until a canonical `state: "review"` export is produced and explicitly approved again.
|
|
28
32
|
|
|
@@ -75,6 +79,24 @@ Re-derive for the requested stack:
|
|
|
75
79
|
|
|
76
80
|
Do not automatically preserve source Engineering Enabler IDs. Product Feature IDs may remain traceable when the semantic Feature is unchanged; record source IDs even when the new implementation re-slices or renumbers work.
|
|
77
81
|
|
|
82
|
+
## Mandatory target reconciliation before proposal
|
|
83
|
+
|
|
84
|
+
Do not treat portable requirements as permission to silently choose implementation/deployment defaults. Before constructing the review manifest, explicitly reconcile the material target-specific choices needed by this Project.
|
|
85
|
+
|
|
86
|
+
At minimum:
|
|
87
|
+
|
|
88
|
+
1. propose the V1 Engineering Enablers required by the selected stack and approved cross-cutting requirements;
|
|
89
|
+
2. distinguish local development/runtime work from remote/Production readiness when both matter;
|
|
90
|
+
3. reconcile deployment outcome/topology using the normal Bootstrap discovery model instead of defaulting it to deferred;
|
|
91
|
+
4. account for approved operational success criteria such as backup/restore, public ingress, or Production availability with explicit enabler/deployment scope when they materially affect V1;
|
|
92
|
+
5. preserve unresolved product decisions as unresolved rather than inventing implementation policy.
|
|
93
|
+
|
|
94
|
+
A replatform proposal must not collapse materially distinct technical readiness responsibilities into one generic Engineering Enabler merely because application scaffolding is deferred.
|
|
95
|
+
|
|
96
|
+
When current Bootstrap replatform tooling requires an explicit reconciliation input, construct it only from the catalog-driven choices and human-approved decisions from this conversation. It must include a non-empty `engineeringEnablers` array and an explicit `deployment` object. Do not synthesize either from stale defaults.
|
|
97
|
+
|
|
98
|
+
If material target-specific choices remain unresolved, keep discovery/reconciliation open and do not manufacture a review-state manifest yet.
|
|
99
|
+
|
|
78
100
|
## New-repository rule
|
|
79
101
|
|
|
80
102
|
Replatforming requires a new target repository identity. The source repository is read-only evidence.
|
|
@@ -94,6 +116,8 @@ Use the current canonical Bootstrap replatform tooling when available. The expec
|
|
|
94
116
|
```text
|
|
95
117
|
approved + canonically valid PROJECT_REQUIREMENTS.json
|
|
96
118
|
+ requested current catalog recipe/stack
|
|
119
|
+
+ explicit reconciled Engineering Enablers
|
|
120
|
+
+ explicit reconciled deployment topology/outcome
|
|
97
121
|
+ target repository identity
|
|
98
122
|
→ PROJECT_BOOTSTRAP.json state=review
|
|
99
123
|
```
|
|
@@ -116,6 +140,8 @@ roadmap maturity
|
|
|
116
140
|
|
|
117
141
|
RE-DERIVED
|
|
118
142
|
stack-specific architecture and Engineering Enablers
|
|
143
|
+
local-development/runtime shape
|
|
144
|
+
deployment outcome/topology and material operational responsibilities
|
|
119
145
|
|
|
120
146
|
TARGET STACK
|
|
121
147
|
resolved current catalog recipe and support state
|