@mriekki/project-forge 4.11.1 → 4.12.0

package/assets/components.json

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 2,
   "package": "@mriekki/project-forge",
-  "version": "4.11.1",
+  "version": "4.12.0",
   "defaultProfile": "greenfield-project",
   "profiles": {
     "greenfield-project": {
@@ -13,7 +13,7 @@
   },
   "components": {
     "core": {
-      "revision": "7a0c5a3ef42c0d6f38203007c957c3e59cbf4f8b",
+      "revision": "ed6a52538a03cb92850cafe0cb8404c39b8e5b89",
       "version": "4.0.0",
       "distribution": "greenfield-workspace",
       "descriptor": "assets/core/distribution.json",

package/assets/generated/ASSEMBLY.json

@@ -1,10 +1,10 @@
 {
   "schemaVersion": 2,
   "package": "@mriekki/project-forge",
-  "version": "4.11.1",
+  "version": "4.12.0",
   "components": {
     "core": {
-      "revision": "7a0c5a3ef42c0d6f38203007c957c3e59cbf4f8b",
+      "revision": "ed6a52538a03cb92850cafe0cb8404c39b8e5b89",
       "version": "4.0.0",
       "distribution": "greenfield-workspace",
       "files": [
@@ -21,7 +21,7 @@
         {
           "source": "core/instructions/project-forge-workflow.instructions.md",
           "destination": ".github/instructions/project-forge-workflow.instructions.md",
-          "sha256": "5b1fffa81451f92f29c839d1219168a72ce625a1d8eed952a9946adf0a66b84b"
+          "sha256": "dd440f677c9ed476bb8b7486500d8acbe2f796272582baadd4d6a60c3d1e662c"
         },
         {
           "source": "core/instructions/project-forge-docs.instructions.md",
@@ -41,17 +41,17 @@
         {
           "source": "core/skills/refine-requirements/SKILL.md",
           "destination": ".github/skills/refine-requirements/SKILL.md",
-          "sha256": "9e76b9c3700a00af8852928d4e6bf1aeca9a24c6cc8fc9b2f1873e0198b63962"
+          "sha256": "5787cd7f70231355b951d58f792665a79da336d6f17ea9f4d6634928ab452623"
         },
         {
           "source": "core/skills/start-work/SKILL.md",
           "destination": ".github/skills/start-work/SKILL.md",
-          "sha256": "f054edd5a745489623579d25e334f5fcd6cebd6e73b86970074e7c2444f9af40"
+          "sha256": "d7a592e64a4e64da5a9e03ee34bc4be4b1862c0d56ed5c71a657e268b4b8e9e5"
         },
         {
           "source": "core/skills/setup/SKILL.md",
           "destination": ".github/skills/setup/SKILL.md",
-          "sha256": "9b3dee1d965f1999490d0e3c58925c341ac5f3f5b228ccfe6a0ac53d64b19a64"
+          "sha256": "d1c6e7a0a04a1fb358b136ed8f83495c27bf8959ebd8941a3d42397fa4dcbaf1"
         },
         {
           "source": "core/skills/build/SKILL.md",
@@ -66,12 +66,12 @@
         {
           "source": "core/skills/export-requirements/SKILL.md",
           "destination": ".github/skills/export-requirements/SKILL.md",
-          "sha256": "6ef2675eafdbcc809f6fb9533ab41ff032a1f3ff4789b1d5825d27cf696d0715"
+          "sha256": "dd82f05b6e2ec7ecf8e7a8592066fd8c6d623c1f184f49838b1e95eb5b53320a"
         },
         {
           "source": "core/skills/replatform/SKILL.md",
           "destination": ".github/skills/replatform/SKILL.md",
-          "sha256": "86e17bf376f395e5f5f018d8def7f5d99b9f4baef30c0b1d20f5caaac5c993c8"
+          "sha256": "561796a829b9c12f8bd2e526f8fe86cbd33d258a5c6b04ca581721e07d984ca7"
         },
         {
           "source": "core/skills/progress/SKILL.md",
@@ -91,7 +91,7 @@
         {
           "source": "core/skills/work-item-status/SKILL.md",
           "destination": ".github/skills/work-item-status/SKILL.md",
-          "sha256": "7235ceebebc61519f2aa6c903ab8e814ba33cb029db4b7e5626852f935038c3c"
+          "sha256": "ca79843e59e5f50785c3621b6bf8ecb7413307aefce05fec737321589792c3a9"
         },
         {
           "source": "core/skills/cleanup-branches/SKILL.md",
@@ -181,7 +181,7 @@
         {
           "source": "core/process/HUMAN_GATES.md",
           "destination": "docs/process/HUMAN_IN_LOOP_GATES.md",
-          "sha256": "ac6ab2343728679d2ae50e9872b4b2f52a49605a2ea7ed17d806a839da4376c1"
+          "sha256": "edad6bd5c659a1cbc6960ce76c269547ec616505b320409b6d3152326d4beaae"
         },
         {
           "source": "core/process/GUIDED_NEXT_STEPS.md",
@@ -191,7 +191,7 @@
         {
           "source": "core/process/INTERACTIVE_SESSION_GUIDE.md",
           "destination": "docs/process/INTERACTIVE_SESSION_GUIDE.md",
-          "sha256": "159bd76122f49be9f2a31d5766fb8a06e9179caef8c6c3eb03bc750685fe73f6"
+          "sha256": "9c4d2ef7eb974faea83dcd1c07c0684aaf351bfebe09186ef7e03cdf1c075c51"
         },
         {
           "source": "core/process/COACHING_GUIDE.md",
@@ -221,7 +221,7 @@
         {
           "source": "core/process/SETUP_ACCEPTANCE_CHECKLIST.md",
           "destination": "docs/process/SETUP_ACCEPTANCE_CHECKLIST.md",
-          "sha256": "b5f8b39de15b464a1c80b26a6c150c6d2a363751abc05d33df4cebcad6b49d9b"
+          "sha256": "92174c10920f536c9912719a630e07e11c525fa2a7913d239bd097fb67f193a0"
         },
         {
           "source": "core/process/OPERATION_JOURNAL.md",
@@ -326,17 +326,17 @@
         {
           "source": "tools/vscode_work_item_status/extension/package.json",
           "destination": "tools/project-forge-vscode/work-item-status/extension/package.json",
-          "sha256": "3ae6351df5aa0fa4908e0e4456c84ac6e9477fde0074226d1aac0316f23b9116"
+          "sha256": "09225a1d9a8a7ceebbba82aafb93a26342da10f1322949cf22061e40196e29df"
         },
         {
           "source": "tools/vscode_work_item_status/extension/extension.js",
           "destination": "tools/project-forge-vscode/work-item-status/extension/extension.js",
-          "sha256": "50b7551c1abc1c30552945dedaf602569dfdf770cad0b2d4652e46f2910231d8"
+          "sha256": "b4e70183bb101d879cc0d7834c51ee4cc48683339fca2c390eb3e49a3a3acdac"
         },
         {
           "source": "tools/vscode_work_item_status/extension/README.md",
           "destination": "tools/project-forge-vscode/work-item-status/extension/README.md",
-          "sha256": "9e1d1e8b53d27c07e8de72d38db420740d7e1b3301ab146531d89882cd088418"
+          "sha256": "b8fc17974024a84ee12f0fe43c38d379916e9e378f7c1efbf9a14da610af60e8"
         },
         {
           "source": "tools/package/check_baseline.py",

package/assets/generated/core/core/instructions/project-forge-workflow.instructions.md

@@ -14,6 +14,14 @@ Use proportional rigor: `LIGHT`, `STANDARD`, `ELEVATED`.
 
 Keep explicit human gates for material requirements, substantive plans, meaningful implementation acceptance, the final merge/delivery decision, and production deployment.
 
+Before any substantive approval gate, identify the exact PRIMARY review subject and put the best available review surface in front of the human when the host supports it. Treat supporting documents as CONTEXT or TRACEABILITY instead of opening everything. For Markdown prefer rendered preview, for structured approval artifacts prefer formatted source plus a concise summary, for implementation acceptance prefer the meaningful diff/Source Control surface, and for plans prefer the native plan surface or durable plan document. Opening or foregrounding a review surface is read-only presentation and never implies approval.
+
+In VS Code, when the Project Forge companion extension is installed and the host can invoke VS Code commands, `projectForge.openReviewArtifact` may be used to foreground an exact workspace-relative repository artifact. Use a stronger native host review/diff surface when available.
+
+For STANDARD/ELEVATED work, invoking `/start-work` authorizes context resolution, risk assessment, and planning only. It does **not** authorize substantive implementation or implementation branch setup by itself. Produce the final proposed plan, foreground its review surface, state that implementation has not started, and require an explicit `Approve plan and begin implementation [PLAN APPROVAL + CODE WRITE]` action before code writes or routine implementation branch setup. For ELEVATED work, Reviewer challenges the plan and material findings are reconciled before the human reviews the final proposed plan.
+
+If implementation later requires a material change to the approved architecture, scope, schema/data handling, security model, externally visible behavior, major dependencies, or verification strategy, reopen the implementation-plan gate with the revised plan before continuing.
+
 Once a bounded action is authorized, routine mechanics inside that scope should proceed without repeated ceremonial confirmation.
 
 For implementation, establish the repository-appropriate short-lived work branch as routine setup once implementation itself is authorized; do not add a separate branch-creation gate when branch policy/naming and scope are clear.

package/assets/generated/core/core/process/HUMAN_GATES.md

@@ -18,10 +18,73 @@ Workspace/setup acceptance is distinct from generation or installation. Generate
 
 A human gate is meaningful only when the human understands what is being approved. If the explanation immediately before a gate did not land, re-explain it before asking for approval again. `/wait-what` is the standard read-only communication-repair path when available; invoking it never implies approval of the pending action.
 
+## Human review surface contract
+
+Before asking for any substantive human approval, identify the exact **review subject** and put the best available review surface in front of the human.
+
+Classify review material when more than one artifact is relevant:
+
+```text
+PRIMARY — the artifact/diff/plan the human is deciding on
+CONTEXT — supporting material that may help review
+TRACEABILITY — provenance/reference material that is not itself being approved
+```
+
+When the current host supports opening or foregrounding the PRIMARY review surface, do so automatically immediately before the gate. Prefer the surface that best matches the decision:
+
+- Markdown requirements, briefs, ADRs, and design documents → rendered Markdown preview when available;
+- structured JSON approval artifacts → formatted source/editor preview plus a concise human-readable summary;
+- implementation plans → the host's native plan surface, or a durable plan document when one exists;
+- implementation acceptance → the meaningful local diff / Source Control review rather than a prose-only file list;
+- final PR acceptance → the observed PR/diff at the exact reviewed head;
+- other repository artifacts → the host's safest read-only preview/editor surface.
+
+Do not open every supporting document and steal focus. Open the PRIMARY surface; name CONTEXT and TRACEABILITY material explicitly and make it easy to open when needed.
+
+If the host cannot open the review surface automatically, provide an explicit path/link and enough concise review context that the human knows exactly what to inspect. Never imply that a path reference alone is equivalent to review.
+
+Opening, previewing, foregrounding, or navigating to a review surface is **read-only presentation**. It never communicates approval, authorization, or acceptance. Only the explicit gate choice does that.
+
 Do not gate routine mechanics individually after a bounded action is already authorized.
 
 Missing access to GitHub admin policy metadata is not itself a human gate. Use configured workflow/check results, PR mergeability, repository documentation, and any observable enforced policy as evidence. Do not ask the human to open GitHub Settings and transcribe branch-protection/ruleset check names merely to continue; ask only when unavailable policy information creates a material unresolved decision at merge, release, or another consequential action.
 
+## Implementation-plan review gate
+
+For STANDARD/ELEVATED work, invoking `/start-work` authorizes requirement/context inspection, risk assessment, and implementation planning. It does **not** authorize substantive implementation by itself.
+
+The required boundary is:
+
+```text
+requirements/context ready
+→ implementation plan produced
+→ PRIMARY plan review surface opened/foregrounded when supported
+→ HUMAN IMPLEMENTATION-PLAN APPROVAL
+→ short-lived work branch setup
+→ substantive implementation
+```
+
+Before the approval choice, state unambiguously that implementation has **not** started. The gate should identify the work item, risk level, review subject, key plan coverage, and any unresolved material decisions.
+
+Use an explicit action set equivalent to:
+
+```text
+IMPLEMENTATION PLAN REVIEW REQUIRED
+
+Implementation has NOT started.
+
+1. Approve plan and begin implementation [PLAN APPROVAL + CODE WRITE]
+2. Request changes to the plan [PLAN ONLY]
+3. Review assumptions / risks [READ ONLY]
+4. Stop [NO ACTION]
+```
+
+When the host exposes structured choice UI, render these as a single-select decision instead of a numbered menu while preserving the consequence labels.
+
+For ELEVATED work, Reviewer challenges the proposed plan before the human gate. Reconcile material Reviewer findings into the final proposed plan, then put that final plan in front of the human. Do not ask the human to approve an initial plan while separate Reviewer objections remain unresolved.
+
+After approval, routine implementation details may evolve without ceremonial re-approval. Reopen the plan gate when evidence requires a **material** change to approved architecture, scope, schema/data handling, security model, externally visible behavior, major dependencies, or verification strategy. Show what changed, why it changed, and the revised plan before implementation continues.
+
 ## Implementation branch setup
 
 Once implementation itself is authorized, creating/switching to the repository-appropriate short-lived work branch is routine setup, not a separate decision gate, when branch policy/naming and work-item scope are clear and the operation preserves the worktree without history rewriting.

package/assets/generated/core/core/process/INTERACTIVE_SESSION_GUIDE.md

@@ -40,11 +40,38 @@ Presentation rules:
 - use **single-select** when the choices are mutually exclusive or one action is being authorized;
 - use **multi-select** only when selecting several choices at the same time is semantically valid;
 - preserve one-material-question-at-a-time cadence whenever practical even if the host can batch questions;
-- keep consequence/action labels such as `[READ ONLY]`, `[REQUIREMENTS GATE]`, or `[GIT + GITHUB WRITE]` visible when they matter to authorization;
+- keep consequence/action labels such as `[READ ONLY]`, `[REQUIREMENTS GATE]`, `[PLAN APPROVAL + CODE WRITE]`, or `[GIT + GITHUB WRITE]` visible when they matter to authorization;
 - include `Other / specify` or host-supported free-text input when the option set may be incomplete; after `Other / specify`, collect the missing value without forcing another invented menu;
 - accept equivalent free-text answers even when a structured selector is shown, unless the host UI itself requires a selection;
 - map the returned structured value to the same semantic choice the workflow would have accepted by label/text.
 
+### Human review surface presentation
+
+Before a substantive approval gate, follow the review-surface contract in `HUMAN_GATES.md`.
+
+1. Identify the exact PRIMARY review subject.
+2. Separate supporting CONTEXT and TRACEABILITY material when useful.
+3. Put the best available PRIMARY review surface in front of the human before asking for approval.
+4. Only then render the explicit approval/action choice.
+
+Use the host's native surface when it is stronger than prose:
+
+- Markdown artifact → rendered Markdown preview when supported;
+- JSON approval artifact → formatted editor/preview plus a concise summary;
+- implementation plan → native plan surface or durable plan document;
+- implementation acceptance → Source Control / meaningful diff review;
+- PR acceptance → exact PR/diff surface at the observed head.
+
+In VS Code, when the Project Forge companion extension is installed and the host can invoke VS Code commands, `projectForge.openReviewArtifact` is the preferred Project Forge-owned action for repository artifacts. Pass the exact workspace-relative artifact path. The command is presentation-only and must reject targets outside the open workspace. For Markdown it opens rendered preview when available; other supported artifacts open in editor preview.
+
+If the host exposes its own safe resource-opening or diff-opening capability, it may use that directly instead. Do not require the Project Forge command when the host already provides a stronger native review surface.
+
+Do not automatically open every supporting document. Foreground only the PRIMARY review subject and list supporting context explicitly. If automatic opening is unavailable, provide a direct path/link and state that the human must open/review it before approving.
+
+Opening a review surface is never approval. A preview event, editor focus, file read, diff display, or navigation action is read-only presentation and must not advance a gate.
+
+For an implementation-plan gate, explicitly state that implementation has **not** started before offering approval. The approval action must be distinct from plan revision/read-only review actions.
+
 ### Recommendations inside choices
 
 A recommendation is optional advice, not a required field and not an accepted decision.

package/assets/generated/core/core/process/SETUP_ACCEPTANCE_CHECKLIST.md

@@ -31,10 +31,13 @@ After opening/reloading the intended editor workspace:
 - [ ] `Reviewer` is discoverable.
 - [ ] `Coach` is discoverable when the workspace includes coaching.
 - [ ] expected Project Forge skills are discoverable, including `/start-work`, `/deliver`, and `/wait-what` when included by the distribution/capability set.
+- [ ] when local `docs/work-items` folders exist, the Project Forge Work Item Status extension is installed/updated by setup and its Explorer decoration is available after any requested one-time VS Code reload; otherwise this check is not applicable.
 - [ ] path-specific instructions are present when the workspace declares them.
 - [ ] path-specific instructions are recognized/applied for matching files when the host supports them.
 - [ ] the human controls the routine model/tier; the workspace does not silently pin or upgrade it.
 
+The work-item Explorer decoration is an evidence-derived editor view, not a workflow authority. Its installation/readiness is reported separately from application runtime/build readiness.
+
 ## Copilot CLI + VS Code discovery
 
 When GitHub Copilot CLI is an intended execution surface:

package/assets/generated/core/core/skills/export-requirements/SKILL.md

@@ -115,13 +115,32 @@ Preserved UX/cross-cutting constraints: ...
 Roadmap maturity retained: ...
 Implementation-specific material excluded: ...
 Items requiring reconciliation: ...
+```
+
+Then make the artifact itself the PRIMARY review subject. Before asking for approval:
+1. identify `PROJECT_REQUIREMENTS.json` explicitly;
+2. foreground/open the formatted JSON in the best available editor/preview surface when the host supports it;
+3. keep source authorities as CONTEXT/TRACEABILITY rather than opening them all;
+4. only then ask the approval question.
+
+In VS Code, when available, use `projectForge.openReviewArtifact` with `PROJECT_REQUIREMENTS.json`. Opening the file is read-only presentation and never changes its state.
+
+Present a gate equivalent to:
+
+```text
+HUMAN REVIEW REQUIRED
+
+Gate: PORTABLE REQUIREMENTS APPROVAL
+Primary artifact: PROJECT_REQUIREMENTS.json
+Opened: formatted editor preview / <fallback surface>
+Items requiring reconciliation: NONE / list
 
 Approve PROJECT_REQUIREMENTS.json as the portable requirements baseline?
 ```
 
 Only explicit human approval may set `state: "approved"`.
 
-`/export-requirements approve` may perform only that bounded finalization after confirming the reviewed content/evidence has not materially changed.
+`/export-requirements approve` may perform only that bounded finalization after confirming the reviewed content/evidence has not materially changed. If the artifact changed materially since review, reopen the review surface and require approval again.
 
 ## Safety and scope
 

package/assets/generated/core/core/skills/refine-requirements/SKILL.md

@@ -27,6 +27,8 @@ Read only the minimum relevant context. Do not preload unrelated work items. Do
 
 Never assume `Jira Epic == Feature Brief`.
 
+When review/approval will concern a local artifact, classify it as the PRIMARY review subject. Supporting Feature/Product briefs, ADRs, and design documents are CONTEXT or TRACEABILITY unless they are themselves the decision subject.
+
 ## 2. Decide whether detail is warranted
 
 Detailed refinement is useful for behavior such as:
@@ -124,6 +126,8 @@ Then present only relevant actions as a **single-select structured choice** when
 - `Approve local requirements` `[REQUIREMENTS GATE]` when applicable
 - `Stop` `[NO ACTION]`
 
+When the human selects `Review full requirements/work item`, foreground the PRIMARY review surface when the host supports it. For local Markdown requirements, prefer rendered Markdown preview. In VS Code, use `projectForge.openReviewArtifact` with the exact workspace-relative path when available. For an external-primary work item, use the best available external issue/item surface instead of creating a local surrogate solely for preview.
+
 Make a recommendation only when current requirement evidence or a clear engineering tradeoff supports one. If so, mark exactly one choice with the host's `recommended` indicator when that metadata exists; otherwise append `[RECOMMENDED]` to exactly one option label. Briefly explain why in the option description or surrounding prompt. A default/preselected value may match the recommendation, but a default alone must never communicate advice or approval. If there is no clear basis, show the choices without a recommendation and without a preference-implying default. The selected answer, not the recommendation, controls what the session does or records.
 
 If the host has no structured choice UI, present the same relevant choices as a concise numbered or lettered text fallback, preserve `[RECOMMENDED]` on the evidence-backed option when applicable, and accept the number/letter, label, or free-form intent. Do not use the text fallback as the normal VS Code path.
@@ -193,7 +197,26 @@ APPROVED
 
 Human approval is explicit. Do not infer approval from review/planning/implementation.
 
-Before approval report coverage and open material decisions. Only an explicit `[REQUIREMENTS GATE]` choice may change local status to `APPROVED`. When the host offers structured choices, render this approval gate as a single-select action, not a numbered chat menu.
+Before approval:
+1. report coverage and open material decisions;
+2. identify the exact PRIMARY local requirements artifact;
+3. foreground/open that artifact in the best available review surface when the host supports it;
+4. only then render the `[REQUIREMENTS GATE]` choice.
+
+For Markdown requirements in VS Code, prefer rendered preview; when the Project Forge companion command is available, invoke `projectForge.openReviewArtifact` with the exact workspace-relative requirements path. If automatic opening is unavailable, provide the exact path/link and explicitly tell the human that this is the artifact being approved.
+
+The gate should make the review subject unmistakable, for example:
+
+```text
+HUMAN REVIEW REQUIRED
+
+Gate: REQUIREMENTS APPROVAL
+Primary artifact: docs/work-items/<work-item>/requirements.md
+Opened: Markdown Preview / <fallback surface>
+Open material decisions: NONE / list
+```
+
+Only an explicit `[REQUIREMENTS GATE]` choice may change local status to `APPROVED`. Opening the document, viewing the preview, or selecting a read-only review action never changes approval state. When the host offers structured choices, render this approval gate as a single-select action, not a numbered chat menu.
 
 External work-item status/approval follows the external team's conventions; Project Forge must not fabricate a local approval state.
 
@@ -222,4 +245,4 @@ Then offer review, more grilling/refinement, approval when applicable, or stop u
 
 Do not create implementation plans or production code.
 
-When requirements are ready, recommend `/start-work <ID-or-key>`.
+When requirements are ready, recommend `/start-work <ID-or-key>`. That command may prepare the implementation plan, but STANDARD/ELEVATED implementation still requires the distinct plan-approval gate defined by `/start-work`.

package/assets/generated/core/core/skills/replatform/SKILL.md

@@ -119,4 +119,27 @@ OUTPUT
 PROJECT_BOOTSTRAP.json — REVIEW
 ```
 
-Then use the normal material Bootstrap manifest approval gate. Approval of replatform intent is not approval to merge, release, or deploy the resulting implementation.
+Then make `PROJECT_BOOTSTRAP.json` the PRIMARY review subject. Before asking for Bootstrap approval:
+
+1. identify the exact manifest path and target repository identity;
+2. foreground/open the formatted manifest in the best available review/editor surface when the host supports it;
+3. keep source requirements/catalog evidence as CONTEXT/TRACEABILITY rather than opening everything;
+4. only then render the normal material Bootstrap manifest approval gate.
+
+In VS Code, when available, use `projectForge.openReviewArtifact` with the exact workspace-relative `PROJECT_BOOTSTRAP.json` path. Opening the manifest is read-only presentation and never authorizes generation.
+
+Present an explicit surface summary such as:
+
+```text
+HUMAN REVIEW REQUIRED
+
+Gate: BOOTSTRAP MANIFEST APPROVAL
+Primary artifact: PROJECT_BOOTSTRAP.json
+State: REVIEW
+Opened: formatted editor preview / <fallback surface>
+Target: <owner/repository>
+```
+
+If the manifest changes materially after review, foreground the changed manifest and reopen approval rather than reusing stale authorization.
+
+Approval of replatform intent or manifest review is not approval to merge, release, or deploy the resulting implementation.

package/assets/generated/core/core/skills/setup/SKILL.md

@@ -47,6 +47,7 @@ From the repository root inspect only what is needed:
 - `SCAFFOLD_PLAN.json` when present;
 - `.github/project-forge-workspace.json` and Project Forge/component baselines when present;
 - `scripts/setup.ps1` on Windows or `scripts/setup.sh` on macOS;
+- `tools/project-forge-vscode/work-item-status/install.py` and `docs/work-items` when present;
 - current Git branch/status/upstream evidence so setup does not overwrite unrelated work;
 - workstation-local setup/readiness evidence when present;
 - actual workstation OS/platform and machine-local identity needed to describe this workspace instance.
@@ -84,12 +85,13 @@ Prefer a compact result such as:
 ```text
 SETUP STATUS
 
-Workspace ......... READY / NOT CONFIGURED / BLOCKED
-Local runtime ..... READY / STALE / NOT APPLICABLE
-Build/tests ....... READY / STALE / BLOCKED
-Local data ........ READY / NOT APPLICABLE / BLOCKED
-Personal profile .. READY / DEFERRED / BLOCKED
-Remote capability . READY / PARTIAL / NOT CONFIGURED
+Workspace ........... READY / NOT CONFIGURED / BLOCKED
+Local runtime ....... READY / STALE / NOT APPLICABLE
+Build/tests ......... READY / STALE / BLOCKED
+Local data .......... READY / NOT APPLICABLE / BLOCKED
+Personal profile .... READY / DEFERRED / BLOCKED
+Work-item Explorer .. READY / NOT INSTALLED / NOT APPLICABLE / ERROR
+Remote capability ... READY / PARTIAL / NOT CONFIGURED
 
 NEXT
 /setup local | /setup remote | /setup <environment> | /next-step
@@ -126,6 +128,38 @@ A temporary process `PATH` adjustment may prove a diagnosis but does not by itse
 
 Stop before destructive replacement, unrelated machine mutation, secret disclosure, or repair outside the declared setup contract.
 
+### Work-item Explorer decoration
+
+When `tools/project-forge-vscode/work-item-status/install.py` exists, treat the Project Forge-owned VS Code work-item status extension as routine workstation setup when local `docs/work-items` folders are present.
+
+For `/setup status`, remain read-only. If `docs/work-items` exists, run:
+
+```text
+python tools/project-forge-vscode/work-item-status/install.py status --json
+```
+
+Report the returned state as the `Work-item Explorer` setup dimension. If `docs/work-items` does not exist, report `NOT APPLICABLE` and do not create a local work-item hierarchy merely to enable badges.
+
+For normal `/setup` and `/setup local`, when `docs/work-items` exists, run the bounded Project Forge installer:
+
+```text
+python tools/project-forge-vscode/work-item-status/install.py install --json
+```
+
+This installation is already authorized by `/setup` as routine workstation preparation; do not require a second `/work-item-status enable` confirmation. The installer may replace older versions of this same Project Forge extension only and must not install unrelated extensions, alter Project files, or change Git/GitHub state.
+
+If the result has `reloadRequired: true`, tell the developer to reload VS Code once after setup. Do not repeatedly reinstall an already-ready version merely because the editor has not yet been reloaded.
+
+If a Project has local `docs/work-items` but the package-managed installer is absent, report:
+
+```text
+PROJECT FORGE UPDATE NEEDED
+```
+
+Route to `/project-forge-update`; do not clone private Project Forge source repositories or download loose extension files as a workaround.
+
+A decorator installation error does not erase otherwise valid runtime/build readiness. Report the `Work-item Explorer` dimension as `ACTION NEEDED` or `ERROR`, preserve the other independent setup dimensions, and give the smallest repair/update action.
+
 ## 4. `/setup local` converges verified local development readiness
 
 The first success target is:
@@ -485,6 +519,7 @@ SETUP RESULT
 Local tools/runtime ......... VERIFIED / BLOCKED / NOT APPLICABLE
 Fresh-shell discovery ....... VERIFIED / CAVEAT / BLOCKED
 Build/tests ................. VERIFIED / BLOCKED / NOT RUN
+Work-item Explorer .......... READY / ACTION NEEDED / NOT APPLICABLE
 Remote target access ........ VERIFIED / BLOCKED / NOT CONFIGURED
 Host platform ............... READY / BLOCKED / NOT APPLICABLE
 Deployment path ............. PROVEN / NOT PROVEN / BLOCKED

package/assets/generated/core/core/skills/start-work/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: start-work
-description: Assess requirement readiness and implementation risk, then guide direct Agent work or native planning for the configured work item.
+description: Assess requirement readiness and implementation risk, prepare and review the implementation plan when warranted, then begin bounded implementation only after the required human authorization.
 argument-hint: "<work-item ID, external key, or concise change>"
 user-invocable: true
 disable-model-invocation: true
@@ -8,6 +8,22 @@ disable-model-invocation: true
 
 # Start Work
 
+## 0. Invocation and implementation boundary
+
+`/start-work` is the orchestration entry point for preparing a work item to be implemented. Its invocation authorizes read-only context resolution, requirement-readiness assessment, risk classification, and implementation planning.
+
+For **STANDARD** and **ELEVATED** work, invoking `/start-work` does **not** by itself authorize substantive implementation, code writes, or implementation branch setup. Those begin only after the human explicitly approves the final proposed implementation plan at the plan gate defined below.
+
+For **LIGHT** work, there is no mandatory formal plan. The human-selected implementation action may authorize bounded implementation directly when the scope is tiny, obvious, and low-risk.
+
+Never blur these states:
+
+```text
+/start-work invoked
+≠ plan approved
+≠ implementation authorized
+```
+
 ## 1. Resolve the requested work
 
 Read `.github/project-forge-workspace.json` when present.
@@ -22,6 +38,8 @@ Resolve only the context needed:
 
 Do not require local briefs when the repository uses Jira/Issues. Do not invent external content.
 
+When the host can open repository review surfaces, foreground the PRIMARY authoritative requirement/work-item artifact when human review is needed. Treat additional briefs/ADRs/design documents as CONTEXT or TRACEABILITY unless they are themselves the approval subject.
+
 ## 2. Check requirement readiness before planning
 
 Assess:
@@ -43,7 +61,7 @@ Are material decisions unresolved?
 
 If detailed precision is warranted but incomplete, recommend `/refine-requirements` or `/grill-me` rather than silently inventing behavior. `/grill-me` may remain read-only or, when the human selects its session-level reconciliation option, write resolved decisions into permitted authorities.
 
-If local requirements are DRAFT and carry material behavior, human approval is the gate before substantive planning/implementation.
+If local requirements are DRAFT and carry material behavior, human approval is the gate before substantive planning/implementation. Before that approval, follow `HUMAN_GATES.md`: identify and foreground the PRIMARY requirements review surface when the host supports it.
 
 If requirements are already sufficient/approved under the configured model, do not force another refinement cycle.
 
@@ -62,7 +80,9 @@ Do not ask the human to open GitHub Settings and transcribe required-check names
 Tiny, obvious, low-risk; no meaningful schema/security/concurrency/deployment/major-UX implications.
 
 ```text
-Agent
+human selects bounded implementation action
+→ short-lived branch setup when appropriate
+→ Agent
 → relevant checks
 → human meaningful-diff review
 ```
@@ -76,7 +96,8 @@ Meaningful multi-file work.
 ```text
 requirements ready as needed
 → native plan
-→ HUMAN PLAN APPROVAL
+→ plan review surface foregrounded
+→ HUMAN IMPLEMENTATION-PLAN APPROVAL
 → short-lived work branch setup
 → Agent implementation
 → checks
@@ -99,7 +120,9 @@ Use for:
 detailed approved requirements / ADR as needed
 → native plan
 → Reviewer challenges plan
-→ HUMAN PLAN APPROVAL
+→ Reviewer findings reconciled into final proposed plan
+→ final plan review surface foregrounded
+→ HUMAN IMPLEMENTATION-PLAN APPROVAL
 → short-lived work branch setup
 → implementation in small slices
 → stronger verification
@@ -121,24 +144,100 @@ Relevant choices are:
 
 Use a numbered text list only when structured choice UI is unavailable. For LIGHT work, do not interrupt with coaching unless requested.
 
-## 5. Planning rules
+## 5. Planning rules and mandatory plan gate
 
 For STANDARD/ELEVATED work:
-- use the editor's current native planning capability,
-- plan approach, affected areas, key decisions, risks, and verification,
-- require human plan approval before implementation,
-- do not auto-launch subagents,
-- do not create mandatory `spec.md` or `tasks.md`,
-- save a durable plan only when it is useful across sessions or for genuinely complex/risky work.
+- use the editor's current native planning capability;
+- plan approach, affected areas, key decisions, risks, non-scope, and verification;
+- do not auto-launch implementation subagents while planning;
+- do not create mandatory `spec.md` or `tasks.md`;
+- save a durable plan only when it is useful across sessions or for genuinely complex/risky work;
+- require explicit human plan approval before implementation or implementation branch setup.
+
+For ELEVATED work, Reviewer challenges the proposed plan before the human approval gate. Reconcile material Reviewer findings into the final proposed plan first. The human reviews that final plan, not an earlier plan plus unresolved reviewer objections.
+
+### Present the review surface before asking for approval
+
+Follow the human-review-surface contract from `HUMAN_GATES.md` and `INTERACTIVE_SESSION_GUIDE.md`.
+
+PRIMARY review subject is the final proposed implementation plan. Prefer:
+1. the host's native plan surface when it can be foregrounded;
+2. a durable plan document when one exists and is useful;
+3. otherwise the full substantive plan in the conversation.
+
+If a durable plan is a repository artifact and VS Code can invoke the Project Forge companion extension, use `projectForge.openReviewArtifact` with the exact workspace-relative path. If the host exposes a stronger native plan/review surface, use that instead.
+
+Before rendering the gate, state explicitly:
+
+```text
+Implementation has NOT started.
+```
+
+Then present a gate equivalent to:
+
+```text
+IMPLEMENTATION PLAN REVIEW REQUIRED
+
+Work item: <ID / key / concise change>
+Risk: <STANDARD | ELEVATED>
+Review subject: <native plan / exact plan path>
+
+Plan covers:
+- approach
+- affected areas
+- key technical decisions
+- risks / mitigations
+- verification strategy
+- explicit non-scope
+
+Open material decisions: <NONE | list>
+
+Implementation has NOT started.
+
+1. Approve plan and begin implementation [PLAN APPROVAL + CODE WRITE]
+2. Request changes to the plan [PLAN ONLY]
+3. Review assumptions / risks [READ ONLY]
+4. Stop [NO ACTION]
+```
+
+When the host exposes structured choice UI, render the actions as a single-select control rather than a numbered menu while preserving the consequence labels. Do not preselect or infer `Approve plan and begin implementation` merely because the plan exists or the human invoked `/start-work`.
+
+Only option 1 (or equivalent explicit free-text authorization) authorizes substantive implementation. Options 2-4 do not.
+
+### Material plan changes after approval
+
+Routine implementation details may evolve inside the approved approach. Reopen the implementation-plan gate when new evidence requires a material change to any of:
+- architecture or major component boundaries,
+- approved scope/non-scope,
+- schema/data handling or migration behavior,
+- authentication/security/authorization model,
+- externally visible behavior or contract,
+- major dependencies/integration strategy,
+- verification strategy when the change materially weakens or alters the approved proof.
+
+Before continuing, show:
+
+```text
+APPROVED PLAN CHANGED
+
+Material change: ...
+Reason: ...
+Revised plan: ...
+```
+
+Foreground the revised PRIMARY plan review surface when supported, then require renewed plan approval. Do not silently continue implementation under stale authorization.
 
 ## 6. Working branch setup
 
 Once implementation is authorized to begin, establish the repository-appropriate short-lived work branch as routine setup before substantive edits.
 
+For STANDARD/ELEVATED work, **plan approval is the implementation authorization boundary**. Do not create/switch the implementation branch merely because `/start-work` was invoked or a plan was produced.
+
 Do not ask a separate branch-creation permission when all of the following are true:
-- the current branch is the default/integration branch and repository policy expects short-lived work branches,
-- the work-item boundary is clear,
-- the target branch name is unambiguous under repository convention or the Project Forge fallback below,
+- implementation is already authorized under the applicable gate;
+- the current branch is the default/integration branch and repository policy expects short-lived work branches;
+- the work-item boundary is clear;
+- the target branch name is unambiguous under repository convention or the Project Forge fallback below;
 - creating/switching branches does not require history rewriting or discarding work.
 
 Branch naming order:
@@ -152,7 +251,7 @@ If scoped uncommitted changes already exist on the default branch and clearly be
 
 Stop and ask only when branch policy/naming is materially ambiguous, the intended branch already exists with divergent work, unrelated changes are present, or the operation would require stash/reset/rebase/force/history rewriting.
 
-For LIGHT work, branch setup is part of the human-selected implementation action. For STANDARD/ELEVATED work, it is part of the approved implementation start after plan approval. Merely inspecting `/start-work` does not authorize implementation before its required gate.
+For LIGHT work, branch setup is part of the human-selected implementation action. For STANDARD/ELEVATED work, it is part of the explicit approved implementation start after plan approval.
 
 ## 7. Deployment enabler
 
@@ -182,10 +281,13 @@ Return:
 - CURRENT STATE,
 - risk level and why,
 - requirement readiness,
-- branch state / expected short-lived branch when implementation is about to begin,
+- current review subject when a human gate is pending,
+- branch state / expected short-lived branch only after implementation is authorized or about to begin,
 - RECOMMENDED NEXT STEP,
 - a small set of relevant action choices.
 
 Render mutually exclusive next actions through the host's **single-select structured choice UI** when available, following `INTERACTIVE_SESSION_GUIDE.md`. In VS Code, use the native question surface such as `vscode_askQuestions`. Make the recommended action visible when evidence supports one, include `Other / specify` or free-text only when the action set may be incomplete, and use a numbered text menu only as the no-structured-UI fallback.
 
-Do not skip an unresolved requirement/plan gate merely because implementation is technically possible. Once implementation is selected/approved, do not insert a separate ceremonial branch-creation gate when the branch setup is safe and deterministic.
+If the workflow has reached the STANDARD/ELEVATED plan gate, stop there until the human selects an explicit plan action. Do not include an alternate implementation action that bypasses the plan gate.
+
+Do not skip an unresolved requirement/plan gate merely because implementation is technically possible. Once implementation is explicitly approved, do not insert a separate ceremonial branch-creation gate when the branch setup is safe and deterministic.

package/assets/generated/core/core/skills/work-item-status/SKILL.md

@@ -10,6 +10,8 @@ disable-model-invocation: true
 
 Purpose: make local `docs/work-items/<ID>-...` folders easier to scan in VS Code without changing work-item paths, ticket content, or Project Forge workflow authority.
 
+Normal `/setup` owns automatic installation/update of this Project Forge extension when local `docs/work-items` folders are present. This command remains the focused read-only inspection and manual enable/disable surface.
+
 Normal use is read-only:
 
 ```text
@@ -72,6 +74,8 @@ python tools/project-forge-vscode/work-item-status/install.py status --json
 
 Also check whether `docs/work-items` exists. If the Project uses an external-only work-item source with no local work-item folders, report the Explorer decoration as not applicable rather than creating a competing local hierarchy.
 
+If local work-item folders are present but the package-managed installer is absent, route to `/project-forge-update`; do not clone Project Forge source repositories or download loose extension files as a workaround.
+
 A useful result is:
 
 ```text
@@ -84,7 +88,7 @@ Project workflow authority . UNCHANGED
 
 ## 4. Enable
 
-`/work-item-status enable` is explicit authorization for one bounded local editor change: install/update the Project Forge-owned extension in this developer's VS Code extensions directory.
+Outside `/setup`, `/work-item-status enable` is explicit authorization for one bounded local editor change: install/update the Project Forge-owned extension in this developer's VS Code extensions directory. Normal `/setup` and `/setup local` already authorize the same bounded install when local `docs/work-items` folders are present, so do not ask for a second confirmation in that flow.
 
 Run:
 
@@ -102,7 +106,7 @@ Project Forge: Refresh Work Item Status
 
 through the VS Code Command Palette.
 
-Failure to install this optional decoration does **not** make Project setup, implementation, review, delivery, or deployment unready.
+Failure to install this editor decoration does **not** make Project setup, implementation, review, delivery, or deployment unready. `/setup` reports the editor dimension separately as action-needed/error and gives the smallest repair/update action without erasing otherwise-valid application/runtime readiness.
 
 ## 5. Disable
 
@@ -124,4 +128,4 @@ Return:
 - a reminder that badges are evidence-derived and non-authoritative;
 - the smallest relevant next action.
 
-Do not turn this optional convenience into a required Project Forge gate.
+Do not turn this editor convenience into a source of Project workflow authority.

package/assets/generated/core/tools/vscode_work_item_status/extension/README.md

@@ -1,11 +1,29 @@
 # Project Forge Work Item Status
 
-This optional local VS Code extension decorates Project Forge work-item folders in the Explorer from repository evidence.
+This optional local VS Code extension decorates Project Forge work-item folders in the Explorer from repository evidence and provides a read-only helper for Project Forge human-review surfaces.
+
+## Work-item status
 
 - `●` — in progress, supported by the current work-item branch or an open pull request.
 - `✓` — complete, supported by a merged pull request to the repository default branch.
 - no badge — no status is asserted.
 
-The extension is read-only. It does not rename or edit work-item folders/documents and does not maintain a second status database. It reads local Git state and, when available, GitHub CLI pull-request metadata. Project Forge's normal repository/PR/CI evidence remains authoritative.
+The status decoration is evidence-derived and non-authoritative. It does not rename or edit work-item folders/documents and does not maintain a second status database. It reads local Git state and, when available, GitHub CLI pull-request metadata. Project Forge's normal repository/PR/CI evidence remains authoritative.
 
 Use **Project Forge: Refresh Work Item Status** from the Command Palette to refresh immediately. The extension also refreshes periodically and when common local Git/work-item evidence changes.
+
+## Human review artifact helper
+
+Project Forge workflows may use **Project Forge: Open Review Artifact** immediately before a human approval gate.
+
+The command accepts an exact workspace-relative repository artifact path when invoked programmatically. When run manually from the Command Palette without a path, it asks for the workspace-relative path.
+
+Behavior:
+
+- Markdown files open in rendered Markdown Preview when available;
+- other repository artifacts open in the normal VS Code editor preview;
+- targets outside the currently open workspace are rejected;
+- missing or ambiguous multi-root targets are reported rather than guessed;
+- opening/previewing an artifact is read-only presentation and never records approval.
+
+Project Forge should foreground only the PRIMARY review subject automatically. Supporting CONTEXT and TRACEABILITY documents remain available without stealing focus unless the human chooses to open them.

package/assets/generated/core/tools/vscode_work_item_status/extension/extension.js

@@ -153,6 +153,138 @@ async function computeRootStatus(root) {
   return { folders, statusById };
 }
 
+function canonicalExistingPath(value) {
+  try {
+    return fs.realpathSync.native
+      ? fs.realpathSync.native(value)
+      : fs.realpathSync(value);
+  } catch {
+    return path.resolve(value);
+  }
+}
+
+function isPathInside(root, candidate) {
+  const canonicalRoot = canonicalExistingPath(root);
+  const canonicalCandidate = canonicalExistingPath(candidate);
+  const relative = path.relative(canonicalRoot, canonicalCandidate);
+  return relative === '' || (
+    relative !== '..' &&
+    !relative.startsWith(`..${path.sep}`) &&
+    !path.isAbsolute(relative)
+  );
+}
+
+function reviewTargetPath(target) {
+  if (typeof target === 'string') {
+    return target.trim();
+  }
+  if (target && typeof target.fsPath === 'string') {
+    return target.fsPath;
+  }
+  if (target && typeof target.path === 'string') {
+    return target.path.trim();
+  }
+  return '';
+}
+
+function isRegularFile(candidate) {
+  try {
+    return fs.statSync(candidate).isFile();
+  } catch {
+    return false;
+  }
+}
+
+async function resolveReviewUri(target) {
+  let requested = reviewTargetPath(target);
+  if (!requested) {
+    requested = (await vscode.window.showInputBox({
+      prompt: 'Workspace-relative Project Forge review artifact path',
+      placeHolder: 'docs/work-items/.../requirements.md',
+      ignoreFocusOut: true,
+    })) || '';
+  }
+  requested = requested.trim();
+  if (!requested) {
+    return undefined;
+  }
+
+  const folders = vscode.workspace.workspaceFolders || [];
+  if (!folders.length) {
+    throw new Error('No VS Code workspace is open.');
+  }
+
+  if (path.isAbsolute(requested)) {
+    const candidate = canonicalExistingPath(requested);
+    const owner = folders.find((folder) => isPathInside(folder.uri.fsPath, candidate));
+    if (!owner) {
+      throw new Error('Review artifact must be inside the open workspace.');
+    }
+    if (!isRegularFile(candidate)) {
+      throw new Error(`Review artifact was not found: ${requested}`);
+    }
+    return vscode.Uri.file(candidate);
+  }
+
+  const matches = [];
+  for (const folder of folders) {
+    const candidate = canonicalExistingPath(path.resolve(folder.uri.fsPath, requested));
+    if (!isPathInside(folder.uri.fsPath, candidate) || !isRegularFile(candidate)) {
+      continue;
+    }
+    matches.push({ folder, uri: vscode.Uri.file(candidate) });
+  }
+
+  if (matches.length === 1) {
+    return matches[0].uri;
+  }
+  if (!matches.length) {
+    throw new Error(`Review artifact was not found in the open workspace: ${requested}`);
+  }
+
+  const activeEditor = vscode.window.activeTextEditor;
+  const activeFolder = activeEditor
+    ? vscode.workspace.getWorkspaceFolder(activeEditor.document.uri)
+    : undefined;
+  const activeMatch = activeFolder
+    ? matches.find((entry) => entry.folder.uri.fsPath === activeFolder.uri.fsPath)
+    : undefined;
+  if (activeMatch) {
+    return activeMatch.uri;
+  }
+
+  throw new Error(`Review artifact path is ambiguous across workspace folders: ${requested}`);
+}
+
+async function openReviewArtifact(target) {
+  try {
+    const uri = await resolveReviewUri(target);
+    if (!uri) {
+      return undefined;
+    }
+
+    const extension = path.extname(uri.fsPath).toLowerCase();
+    if (extension === '.md' || extension === '.markdown') {
+      try {
+        await vscode.commands.executeCommand('markdown.showPreview', uri);
+        return uri.toString();
+      } catch {
+        // Fall back to the normal editor preview surface when Markdown preview is unavailable.
+      }
+    }
+
+    await vscode.commands.executeCommand('vscode.open', uri, {
+      preview: true,
+      preserveFocus: false,
+    });
+    return uri.toString();
+  } catch (error) {
+    const message = error && error.message ? error.message : String(error);
+    await vscode.window.showWarningMessage(`Project Forge review artifact: ${message}`);
+    return undefined;
+  }
+}
+
 class WorkItemDecorationProvider {
   constructor() {
     this._onDidChangeFileDecorations = new vscode.EventEmitter();
@@ -238,6 +370,9 @@ function activate(context) {
   context.subscriptions.push(
     vscode.commands.registerCommand('projectForge.refreshWorkItemStatus', refresh),
   );
+  context.subscriptions.push(
+    vscode.commands.registerCommand('projectForge.openReviewArtifact', openReviewArtifact),
+  );
   context.subscriptions.push(
     vscode.window.onDidChangeWindowState((event) => {
       if (event.focused) {
@@ -271,4 +406,4 @@ function activate(context) {
 
 function deactivate() {}
 
-module.exports = { activate, deactivate };
+module.exports = { activate, deactivate, openReviewArtifact, resolveReviewUri };

package/assets/generated/core/tools/vscode_work_item_status/extension/package.json

@@ -1,8 +1,8 @@
 {
   "name": "project-forge-work-item-status",
   "displayName": "Project Forge Work Item Status",
-  "description": "Shows evidence-backed Project Forge work-item status badges in the VS Code Explorer.",
-  "version": "0.1.0",
+  "description": "Shows evidence-backed Project Forge work-item status badges and provides read-only review-surface helpers in VS Code.",
+  "version": "0.2.0",
   "publisher": "project-forge",
   "license": "UNLICENSED",
   "engines": {
@@ -14,10 +14,12 @@
   "keywords": [
     "project-forge",
     "work-items",
-    "explorer"
+    "explorer",
+    "review"
   ],
   "activationEvents": [
-    "workspaceContains:docs/work-items/*"
+    "workspaceContains:docs/work-items/*",
+    "onCommand:projectForge.openReviewArtifact"
   ],
   "main": "./extension.js",
   "extensionKind": [
@@ -26,7 +28,7 @@
   "capabilities": {
     "untrustedWorkspaces": {
       "supported": false,
-      "description": "The extension reads local Git state and optional GitHub CLI pull-request evidence."
+      "description": "The extension reads local Git state and optional GitHub CLI pull-request evidence, and may open workspace review artifacts on explicit Project Forge commands."
     }
   },
   "contributes": {
@@ -34,6 +36,10 @@
       {
         "command": "projectForge.refreshWorkItemStatus",
         "title": "Project Forge: Refresh Work Item Status"
+      },
+      {
+        "command": "projectForge.openReviewArtifact",
+        "title": "Project Forge: Open Review Artifact"
       }
     ]
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mriekki/project-forge",
-  "version": "4.11.1",
+  "version": "4.12.0",
   "description": "Public consumer distribution and updater for Project Forge engineering assets.",
   "type": "module",
   "bin": {