@mriekki/project-forge 4.13.3 → 4.13.5
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
CHANGED
|
@@ -8,13 +8,13 @@ The Builder brings the idea and makes the material decisions. Project Forge supp
|
|
|
8
8
|
|
|
9
9
|
## What it feels like
|
|
10
10
|
|
|
11
|
-
Start with
|
|
11
|
+
Start with the one Project-creation prompt:
|
|
12
12
|
|
|
13
13
|
```text
|
|
14
|
-
New Project
|
|
14
|
+
New Project
|
|
15
15
|
```
|
|
16
16
|
|
|
17
|
-
Project Forge guides the Builder through:
|
|
17
|
+
Project Forge presents the currently supported ways to begin, explains each option, and then guides the Builder through the path they select. A greenfield path looks like:
|
|
18
18
|
|
|
19
19
|
```text
|
|
20
20
|
idea
|
|
@@ -72,7 +72,8 @@ open personal invitation
|
|
|
72
72
|
→ accept invitation
|
|
73
73
|
→ automatic readiness verification
|
|
74
74
|
→ configure one ChatGPT coding Project
|
|
75
|
-
→ New Project
|
|
75
|
+
→ New Project
|
|
76
|
+
→ choose a supported start mode
|
|
76
77
|
```
|
|
77
78
|
|
|
78
79
|
**Project Forge Builder** is the GitHub App used for Project Forge authorization and project orchestration.
|
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.5",
|
|
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.5",
|
|
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
|