@mriekki/project-forge 4.13.1 → 4.13.2

package/assets/components.json

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 2,
   "package": "@mriekki/project-forge",
-  "version": "4.13.1",
+  "version": "4.13.2",
   "defaultProfile": "greenfield-project",
   "profiles": {
     "greenfield-project": {
@@ -13,7 +13,7 @@
   },
   "components": {
     "core": {
-      "revision": "a88c33ec1c93e120c70018a01c018f59dc2f74f2",
+      "revision": "51fc0332a7908cf8e3ebe5594e864feb5025e853",
       "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.13.1",
+  "version": "4.13.2",
   "components": {
     "core": {
-      "revision": "a88c33ec1c93e120c70018a01c018f59dc2f74f2",
+      "revision": "51fc0332a7908cf8e3ebe5594e864feb5025e853",
       "version": "4.0.0",
       "distribution": "greenfield-workspace",
       "files": [
@@ -71,12 +71,12 @@
         {
           "source": "core/skills/export-requirements/SKILL.md",
           "destination": ".github/skills/export-requirements/SKILL.md",
-          "sha256": "dd82f05b6e2ec7ecf8e7a8592066fd8c6d623c1f184f49838b1e95eb5b53320a"
+          "sha256": "0206e6c754158e46aaacb9f83a7bf2af85827fe6d60fc90a4874d5633946192a"
         },
         {
           "source": "core/skills/replatform/SKILL.md",
           "destination": ".github/skills/replatform/SKILL.md",
-          "sha256": "561796a829b9c12f8bd2e526f8fe86cbd33d258a5c6b04ca581721e07d984ca7"
+          "sha256": "b663ec40bb9b48f5737d8d2141a60c131196d4c496605d0a8c65285a0e7deb8f"
         },
         {
           "source": "core/skills/progress/SKILL.md",
@@ -236,7 +236,7 @@
         {
           "source": "core/process/PROJECT_REQUIREMENTS_EXPORT.md",
           "destination": "docs/process/PROJECT_REQUIREMENTS_EXPORT.md",
-          "sha256": "6ef9ecf1bb7c86b5f445554f5e630db36beee34bead2db8ff2597c148fba9c30"
+          "sha256": "f3e171cf466db69f46798859d9c174c177f5a1cb02bf19a3f02a66a16f5c43df"
         },
         {
           "source": "core/process/APPLICATION_VERSIONING.md",

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

@@ -20,6 +20,33 @@ Additional product/domain authorities may include roadmap, system-design/domain
 
 The export must retain source paths/authority/provenance so a consumer can trace normalized facts back to their repository authorities.
 
+## Canonical contract authority
+
+Core owns the `/export-requirements` workflow and Human-in-the-Loop gate. Bootstrap owns the accepted portable-requirements schema and validator.
+
+At the start of an export session, resolve the current stable Project Forge descriptor:
+
+```text
+https://raw.githubusercontent.com/mriekki/project-forge-platform/main/chatgpt/current.json
+```
+
+Use the exact immutable `generation.bootstrap.revision` selected there. Through authorized Project Forge/GitHub access, inspect that revision's canonical:
+
+```text
+schemas/project-requirements.schema.json
+tools/project_requirements.py
+```
+
+Do not maintain a competing schema in Core and do not use remembered field shapes, generated examples, or a legacy export as structural authority.
+
+If the stable descriptor, exact Bootstrap revision, schema, or validator cannot be resolved, stop before portable-requirements approval with:
+
+```text
+PORTABLE REQUIREMENTS VALIDATION REQUIRED
+```
+
+Unavailability of canonical validation is not permission to infer a compatible shape.
+
 ## Canonical filename and state
 
 Only this filename is canonical:
@@ -42,7 +69,7 @@ Only `approved` may be consumed as replatform input.
 
 ## Portable content model
 
-The export should represent, when present:
+The exact JSON structure comes from the current Bootstrap schema. Within that structure, the export should represent, when present:
 
 - project/product identity;
 - problem, users/stakeholders, desired outcomes, scope/non-scope;
@@ -107,7 +134,7 @@ Examples:
 
 - a Project Blueprint may contain product/domain facts plus current technology baseline;
 - a System Design may contain portable domain invariants plus React/.NET/SQLite topology;
-- a UX pattern may contain portable interaction behavior plus component-library details;
+- a UX pattern may contain portable interaction behavior plus component-library detail;
 - an ADR may establish both a product/security consequence and a stack-specific mechanism.
 
 Extract the portable fact, retain source traceability, and exclude/reconcile the mechanism.
@@ -128,6 +155,23 @@ Do not export as portable requirements unless the repository explicitly makes th
 - Git/PR/CI evidence;
 - Project Forge/Core/Bootstrap baseline state.
 
+## Validation and approval boundary
+
+Create or refresh the derived artifact in `state: "review"`, then validate the exact file with the canonical Bootstrap validator from the exact revision resolved for the session.
+
+Equivalent validation commands are:
+
+```text
+python tools/project_requirements.py PROJECT_REQUIREMENTS.json
+python tools/project_requirements.py PROJECT_REQUIREMENTS.json --require-approved
+```
+
+The first is required before the human review/approval gate. The second is required after the bounded approval-state transition.
+
+If review-state validation fails, repair only the derived export from existing authorities and the canonical schema, then rerun validation. Do not ask for approval until it passes.
+
+If an older or malformed export was previously approved but does not validate now, that earlier approval does not automatically authorize a normalized replacement. Preserve the underlying source authority/maturity/provenance, produce a valid `state: "review"` artifact, and obtain a fresh human approval of that exact artifact.
+
 ## Replatform relationship
 
 The canonical flow is:
@@ -135,9 +179,12 @@ The canonical flow is:
 ```text
 project authorities
 → /export-requirements
+→ current stable Bootstrap contract resolution
 → PROJECT_REQUIREMENTS.json state=review
+→ canonical Bootstrap validation PASS
 → human approval
 → PROJECT_REQUIREMENTS.json state=approved
+→ canonical Bootstrap validation --require-approved PASS
 → /replatform <target-stack>
 → current Bootstrap catalog reconciliation
 → PROJECT_BOOTSTRAP.json state=review

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

@@ -28,6 +28,33 @@ It must not answer:
 
 > Which framework, language, ORM, build tool, folder layout, or CI implementation should the next repository use?
 
+## Canonical Bootstrap contract preflight
+
+Before constructing or refreshing `PROJECT_REQUIREMENTS.json`, resolve the current stable Project Forge descriptor from:
+
+```text
+https://raw.githubusercontent.com/mriekki/project-forge-platform/main/chatgpt/current.json
+```
+
+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.
+
+Through the authorized Project Forge/GitHub access available in the current host, inspect the canonical Bootstrap portable-requirements schema and validator from that exact immutable revision, including:
+
+```text
+schemas/project-requirements.schema.json
+tools/project_requirements.py
+```
+
+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.
+
+If the stable descriptor, exact Bootstrap revision, canonical schema, or canonical validator cannot be resolved and inspected, stop with:
+
+```text
+PORTABLE REQUIREMENTS VALIDATION REQUIRED
+```
+
+Do not create an approval-ready export and do not ask for portable-requirements approval while canonical validation is unavailable.
+
 ## Source model
 
 Start from the workspace's declared authority model. In a normal generated Project Forge workspace, inspect as applicable:
@@ -100,15 +127,35 @@ Do not export as portable requirements:
 - implementation plans, code, review history, branch/PR/CI evidence;
 - generated Project Forge/Core provenance.
 
-## Artifact state and human gate
+## Canonical validation before human review
+
+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.
+
+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:
+
+```text
+python tools/project_requirements.py <path-to-PROJECT_REQUIREMENTS.json>
+```
+
+The actual invocation path may differ by host, but the validator implementation and Bootstrap revision must be the same canonical ones resolved during preflight.
+
+If validation fails:
 
-Default `/export-requirements` writes or refreshes `PROJECT_REQUIREMENTS.json` with `state: "review"` and exact source repository/commit provenance.
+1. report the validator errors;
+2. repair only the derived export using existing source authorities and the canonical schema;
+3. preserve source authority, maturity, provenance, open decisions, and non-authorizing roadmap intent;
+4. rerun canonical validation;
+5. do not ask for approval until validation passes.
 
-Before calling it approved, present a compact reconciliation summary:
+Do not silently reinterpret a rejected legacy/export shape, rename fields from memory, promote unresolved decisions, or treat prior human approval of structurally different JSON as approval of a normalized replacement.
+
+Before calling a valid export approved, present a compact reconciliation summary:
 
 ```text
 PROJECT REQUIREMENTS EXPORT
 
+Bootstrap revision: <exact revision>
+Canonical validation: PASS
 Preserved product/features: ...
 Preserved domain rules: ...
 Preserved UX/cross-cutting constraints: ...
@@ -120,7 +167,7 @@ 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;
+3. keep source authorities and Bootstrap validation evidence 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.
@@ -133,6 +180,7 @@ HUMAN REVIEW REQUIRED
 Gate: PORTABLE REQUIREMENTS APPROVAL
 Primary artifact: PROJECT_REQUIREMENTS.json
 Opened: formatted editor preview / <fallback surface>
+Canonical Bootstrap validation: PASS @ <exact revision>
 Items requiring reconciliation: NONE / list
 
 Approve PROJECT_REQUIREMENTS.json as the portable requirements baseline?
@@ -140,7 +188,13 @@ 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. If the artifact changed materially since review, reopen the review surface and require approval again.
+`/export-requirements approve` may perform only that bounded finalization after confirming the reviewed content/evidence has not materially changed. After changing `state` to `approved`, rerun the same canonical Bootstrap validator with the equivalent of:
+
+```text
+python tools/project_requirements.py <path-to-PROJECT_REQUIREMENTS.json> --require-approved
+```
+
+If final validation fails, restore/report review state as applicable and do not claim the portable baseline is approved. If the artifact changed materially since review for any reason beyond the bounded approval-state transition, reopen the review surface and require approval again.
 
 ## Safety and scope
 

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

@@ -22,6 +22,10 @@ PROJECT_REQUIREMENTS.json
 
 The file must be `state: "approved"`. Do not accept alternate/legacy requirements-export filenames or infer approval from file existence.
 
+Before consuming the export, validate it with the canonical Bootstrap portable-requirements validator from the exact current stable Bootstrap revision. If it fails canonical validation, stop and route back through `/export-requirements`; do not normalize, translate, alias, or repair the input inside `/replatform`.
+
+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.
+
 If the export is missing or stale relative to material source-requirement changes, use `/export-requirements` first.
 
 ## Target
@@ -88,7 +92,7 @@ Never:
 Use the current canonical Bootstrap replatform tooling when available. The expected deterministic boundary is:
 
 ```text
-approved PROJECT_REQUIREMENTS.json
+approved + canonically valid PROJECT_REQUIREMENTS.json
 + requested current catalog recipe/stack
 + target repository identity
 → PROJECT_BOOTSTRAP.json state=review
@@ -104,6 +108,7 @@ Before generation, summarize at minimum:
 SOURCE REQUIREMENTS
 source repository/commit
 portable requirements export provenance
+canonical Bootstrap validation evidence
 
 PRESERVED
 product/features/domain/UX/cross-cutting intent

package/package.json

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