@mriekki/project-forge 4.13.3 → 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": [
|
|
@@ -76,7 +76,7 @@
|
|
|
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",
|
|
@@ -79,6 +79,24 @@ Re-derive for the requested stack:
|
|
|
79
79
|
|
|
80
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.
|
|
81
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
|
+
|
|
82
100
|
## New-repository rule
|
|
83
101
|
|
|
84
102
|
Replatforming requires a new target repository identity. The source repository is read-only evidence.
|
|
@@ -98,6 +116,8 @@ Use the current canonical Bootstrap replatform tooling when available. The expec
|
|
|
98
116
|
```text
|
|
99
117
|
approved + canonically valid PROJECT_REQUIREMENTS.json
|
|
100
118
|
+ requested current catalog recipe/stack
|
|
119
|
+
+ explicit reconciled Engineering Enablers
|
|
120
|
+
+ explicit reconciled deployment topology/outcome
|
|
101
121
|
+ target repository identity
|
|
102
122
|
→ PROJECT_BOOTSTRAP.json state=review
|
|
103
123
|
```
|
|
@@ -120,6 +140,8 @@ roadmap maturity
|
|
|
120
140
|
|
|
121
141
|
RE-DERIVED
|
|
122
142
|
stack-specific architecture and Engineering Enablers
|
|
143
|
+
local-development/runtime shape
|
|
144
|
+
deployment outcome/topology and material operational responsibilities
|
|
123
145
|
|
|
124
146
|
TARGET STACK
|
|
125
147
|
resolved current catalog recipe and support state
|