@mriekki/project-forge 4.5.0 → 4.6.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/assets/components.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"schemaVersion": 2,
|
|
3
3
|
"package": "@mriekki/project-forge",
|
|
4
|
-
"version": "4.
|
|
4
|
+
"version": "4.6.0",
|
|
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": "ff91df577814d4ef398fe5a931f8a8343a5c024c",
|
|
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.
|
|
4
|
+
"version": "4.6.0",
|
|
5
5
|
"components": {
|
|
6
6
|
"core": {
|
|
7
|
-
"revision": "
|
|
7
|
+
"revision": "ff91df577814d4ef398fe5a931f8a8343a5c024c",
|
|
8
8
|
"version": "4.0.0",
|
|
9
9
|
"distribution": "greenfield-workspace",
|
|
10
10
|
"files": [
|
|
@@ -21,7 +21,7 @@
|
|
|
21
21
|
{
|
|
22
22
|
"source": "core/instructions/project-forge-workflow.instructions.md",
|
|
23
23
|
"destination": ".github/instructions/project-forge-workflow.instructions.md",
|
|
24
|
-
"sha256": "
|
|
24
|
+
"sha256": "5b1fffa81451f92f29c839d1219168a72ce625a1d8eed952a9946adf0a66b84b"
|
|
25
25
|
},
|
|
26
26
|
{
|
|
27
27
|
"source": "core/instructions/project-forge-docs.instructions.md",
|
|
@@ -186,7 +186,7 @@
|
|
|
186
186
|
{
|
|
187
187
|
"source": "core/process/INTERACTIVE_SESSION_GUIDE.md",
|
|
188
188
|
"destination": "docs/process/INTERACTIVE_SESSION_GUIDE.md",
|
|
189
|
-
"sha256": "
|
|
189
|
+
"sha256": "159bd76122f49be9f2a31d5766fb8a06e9179caef8c6c3eb03bc750685fe73f6"
|
|
190
190
|
},
|
|
191
191
|
{
|
|
192
192
|
"source": "core/process/COACHING_GUIDE.md",
|
|
@@ -22,6 +22,8 @@ Continuous modes such as `/grill-me`, `/refine-requirements`, `/coach`, `/learni
|
|
|
22
22
|
|
|
23
23
|
During interactive questioning, prefer concise choice-first options for genuinely bounded human decisions, including `Other / specify` and `Not sure — recommend one` when appropriate. When the host exposes native structured question controls, use them instead of a plain numbered chat list. In VS Code, use the host's structured question surface such as `vscode_askQuestions` when available: single-select for mutually exclusive decisions/actions and multi-select only when several simultaneous selections are valid. A textual numbered or lettered menu is only the fallback when structured choice UI is unavailable.
|
|
24
24
|
|
|
25
|
+
When an authorized action requires a developer-owned interactive terminal prompt, follow the interactive-terminal handoff in `INTERACTIVE_SESSION_GUIDE.md`: collect any distinct bounded authorization first through the host-native structured control, then immediately provide the exact command in a standalone fenced code block, state the working directory when relevant, explain the local prompt briefly, keep passphrases/passwords/tokens/private keys local to the terminal, and say what result to report back for deterministic verification. Do not make the inability to inject terminal keystrokes the main response when a copyable command is sufficient. If the host can insert terminal text, insert only the non-secret command for human review/execution rather than silently executing the interactive step.
|
|
26
|
+
|
|
25
27
|
Make a recommendation only when current evidence, repository policy, or a clear engineering tradeoff supports one. Mark exactly one supported choice with the host's `recommended` indicator when available and give a brief rationale. When the host does not expose recommendation metadata, append `[RECOMMENDED]` to exactly one option label and keep the rationale visible. A default/preselected option may match the recommendation, but a default alone must never communicate advice or human approval. If no option is clearly better, do not mark any option recommended and do not use a default that implies a preference. A recommendation is advice, not approval: record only the human's selected/confirmed answer. If the human asks for no recommendation on one decision, honor that for that decision only; later questions may still include evidence-backed recommendations.
|
|
26
28
|
|
|
27
29
|
Keep factual/environment-specific values and questions intended to elicit the human's own framing, reasoning, debugging approach, design rationale, or understanding open-ended unless options are later useful as scaffolding.
|
|
@@ -30,6 +32,8 @@ Keep factual/environment-specific values and questions intended to elicit the hu
|
|
|
30
32
|
|
|
31
33
|
`/setup` is the single workstation/environment preparation entry point. It owns status, repair, verified local runtime convergence, remote-enabled capability preparation, and named-environment setup/proof. Do not create a second developer-environment-mode command. `/deployment-readiness <environment>` remains the later exact-environment pre-deploy verification step.
|
|
32
34
|
|
|
35
|
+
For `/setup`, apply the interactive-terminal handoff whenever deterministic Project Forge tooling reaches a local prompt that must remain under developer control. For example, after the exact target key-creation action is authorized, provide the returned `project-forge-deploy target key-create <target>` command immediately in a standalone copyable block, tell the developer to enter `[LOCAL KEY WRITE]` and the private-key passphrase only in the terminal, and state the non-secret result/evidence to report back so setup can verify and continue. Do not ask the developer to paste the passphrase or private key into chat and do not turn terminal ownership into a dead-end explanation.
|
|
36
|
+
|
|
33
37
|
For deployment readiness, inspect existing non-secret configuration before asking setup questions. Show already-known simple machine facts such as hostname/address, deployment user, port, and target OS for confirmation. Ask only for missing or conflicting facts. Keep deployment-tool implementation identifiers such as logical target names, `targetName`, SSH aliases, profile paths, and trust-file paths internal unless troubleshooting or genuine ambiguity requires them.
|
|
34
38
|
|
|
35
39
|
Shared managed code keeps its canonical owner. When a consumer contains `CORE_BASELINE.json` or `DEPLOYMENT_BASELINE.json`, treat those baselines as ownership evidence. A temporary edit to a shared-managed consumer file may be used to diagnose or prove a reusable defect, but it is not the canonical deliverable.
|
|
@@ -64,6 +64,17 @@ A structured selector is presentation, not extra authorization. Selecting a choi
|
|
|
64
64
|
|
|
65
65
|
When the host has no structured question UI, use a concise textual fallback. A numbered or lettered list is acceptable **only as this fallback**; keep the same labels/recommendation/consequence tags, including `[RECOMMENDED]` when one option is evidence-backed, and accept the number/letter, label, or a free-form answer. Do not use a plain numbered list as the normal VS Code interaction when native structured choice UI is available.
|
|
66
66
|
|
|
67
|
+
### Interactive terminal handoff
|
|
68
|
+
|
|
69
|
+
When an authorized action must run in the developer's own terminal because it requires an interactive prompt, secure local input, or another terminal-owned interaction, treat the command handoff as continuation of the workflow rather than as a generic blocker.
|
|
70
|
+
|
|
71
|
+
- If the action has its own bounded authorization, collect that authorization first through the host-native structured question control when available. Once the exact action is authorized, do not ask for the same permission again merely because execution moves to the terminal.
|
|
72
|
+
- Immediately after authorization, provide the exact command in a **standalone fenced code block**. State the working directory when it is not already unambiguous. Do not bury the command inside explanatory prose.
|
|
73
|
+
- Briefly describe the local prompt the developer should expect and which sensitive values must be entered **only in the terminal**. Never ask for a passphrase, password, token, private key, or other secret through chat, and never place such a secret in the command arguments merely to avoid an interactive prompt.
|
|
74
|
+
- State what observable result or concise evidence the developer should report back so the workflow can verify the action and continue. Prefer deterministic verification after the local step instead of asking for secret-bearing terminal transcripts.
|
|
75
|
+
- Do not lead with or dwell on the assistant's inability to send keystrokes when a copyable command is an adequate path forward. Capability limitations may be stated briefly only when they materially affect the next action.
|
|
76
|
+
- If the host exposes terminal-send support, it may insert the exact non-secret command for **human review/execution** rather than silently executing an interactive command. Keep interactive secret input local and never inject it through the host automation channel.
|
|
77
|
+
|
|
67
78
|
Keep questions open-ended when predefined choices would weaken the purpose of the interaction. This includes:
|
|
68
79
|
|
|
69
80
|
- user-authored problem/outcome/workflow framing where the human's own wording matters;
|