@mriekki/project-forge 4.13.1 → 4.13.3

package/assets/components.json

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 2,
   "package": "@mriekki/project-forge",
-  "version": "4.13.1",
+  "version": "4.13.3",
   "defaultProfile": "greenfield-project",
   "profiles": {
     "greenfield-project": {
@@ -13,7 +13,7 @@
   },
   "components": {
     "core": {
-      "revision": "a88c33ec1c93e120c70018a01c018f59dc2f74f2",
+      "revision": "13efbc5c8e368704a780c88bba6d42165664a74a",
       "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.3",
   "components": {
     "core": {
-      "revision": "a88c33ec1c93e120c70018a01c018f59dc2f74f2",
+      "revision": "13efbc5c8e368704a780c88bba6d42165664a74a",
       "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": "05d2ce830b2924f3508641f6bfa056f577862f27d236526f5a217a790d1ad490"
         },
         {
           "source": "core/skills/replatform/SKILL.md",
           "destination": ".github/skills/replatform/SKILL.md",
-          "sha256": "561796a829b9c12f8bd2e526f8fe86cbd33d258a5c6b04ca581721e07d984ca7"
+          "sha256": "f2d7e8d0b940fabeae15150d80a758c8b2980a54b0bc47040d07e9703a4cf044"
         },
         {
           "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,36 @@ 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.
+
+The stable descriptor must provide `generation.bootstrap.portableRequirements` with public immutable locators for the canonical schema and validator. Require all of the following before continuing:
+
+- `portableRequirements.bootstrapRevision` exactly equals `generation.bootstrap.revision`;
+- `portableRequirements.schema.path` equals `schemas/project-requirements.schema.json`;
+- `portableRequirements.validator.path` equals `tools/project_requirements.py`;
+- both locator URLs resolve from an immutable public Platform commit rather than a mutable branch;
+- both advertised SHA-256 values match the retrieved bytes.
+
+Fetch and inspect the schema and validator through those public locators. Do not infer or expose the private foundational repository from the bare Bootstrap revision, and do not substitute similarly named files discovered through code search.
+
+Bootstrap owns the schema/validator. Platform publishes the reviewed public immutable mirrors/locators. 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, public locator metadata, canonical schema, canonical validator, or digest verification 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 +130,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.
+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 calling it approved, present a compact reconciliation summary:
+Before presenting any approval question, validate that exact file with the canonical Bootstrap validator retrieved and digest-verified from the public locator for the exact revision resolved during preflight. The equivalent canonical source-layout invocation is:
+
+```text
+python tools/project_requirements.py <path-to-PROJECT_REQUIREMENTS.json>
+```
+
+The actual local path may differ by host, but the validator bytes and Bootstrap revision must be the same canonical ones resolved and verified during preflight.
+
+If validation fails:
+
+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.
+
+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 +170,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 +183,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 +191,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,14 @@ 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 resolved from the current stable Project Forge descriptor and its `generation.bootstrap.portableRequirements` metadata. Require `portableRequirements.bootstrapRevision` to equal `generation.bootstrap.revision`, fetch the canonical validator from the advertised immutable public locator, verify its advertised SHA-256, and validate the export with that exact validator using `--require-approved`.
+
+Do not infer or expose the private foundational repository from the Bootstrap revision, and do not substitute similarly named files discovered through code search. If the public locator metadata, canonical validator, digest verification, or exact Bootstrap revision cannot be resolved, stop with `PORTABLE REQUIREMENTS VALIDATION REQUIRED`.
+
+If canonical validation fails, 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 +96,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 +112,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.3",
   "description": "Public consumer distribution and updater for Project Forge engineering assets.",
   "type": "module",
   "bin": {