@mriekki/project-forge 2.0.0 → 2.1.0

package/assets/components.json

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 1,
   "package": "@mriekki/project-forge",
-  "version": "2.0.0",
+  "version": "2.1.0",
   "defaultProfile": "greenfield-project",
   "profiles": {
     "greenfield-project": {
@@ -14,8 +14,8 @@
   "components": {
     "core": {
       "repository": "mriekki/project-forge-core",
-      "commit": "80ff581ec89533f5a22bd05c65c7b67bb314c715",
-      "version": "3.0.0",
+      "commit": "fd071b9516cb40093f30be41ab695139eb16bb4c",
+      "version": "3.3.0",
       "distribution": "greenfield-workspace",
       "descriptor": "assets/core/distribution.json",
       "sourceRoot": "assets/generated/core",

package/assets/core/distribution.json

@@ -13,6 +13,10 @@
     {"source":"core/skills/refine-requirements/SKILL.md","destination":".github/skills/refine-requirements/SKILL.md"},
     {"source":"core/skills/start-work/SKILL.md","destination":".github/skills/start-work/SKILL.md"},
     {"source":"core/skills/setup/SKILL.md","destination":".github/skills/setup/SKILL.md"},
+    {"source":"core/skills/build/SKILL.md","destination":".github/skills/build/SKILL.md"},
+    {"source":"core/skills/run/SKILL.md","destination":".github/skills/run/SKILL.md"},
+    {"source":"core/skills/export-requirements/SKILL.md","destination":".github/skills/export-requirements/SKILL.md"},
+    {"source":"core/skills/replatform/SKILL.md","destination":".github/skills/replatform/SKILL.md"},
     {"source":"core/skills/progress/SKILL.md","destination":".github/skills/progress/SKILL.md"},
     {"source":"core/skills/next-step/SKILL.md","destination":".github/skills/next-step/SKILL.md"},
     {"source":"core/skills/deliver/SKILL.md","destination":".github/skills/deliver/SKILL.md"},
@@ -44,6 +48,9 @@
     {"source":"core/process/PROJECT_DOCUMENTATION_FRAMEWORK.md","destination":"docs/process/PROJECT_DOCUMENTATION_FRAMEWORK.md"},
     {"source":"core/process/PROJECT_FORGE_ENGINEERING_GUIDE.md","destination":"docs/project-forge/PROJECT_FORGE_ENGINEERING_GUIDE.md"},
     {"source":"core/process/SETUP_ACCEPTANCE_CHECKLIST.md","destination":"docs/process/SETUP_ACCEPTANCE_CHECKLIST.md"},
+    {"source":"core/process/OPERATION_JOURNAL.md","destination":"docs/process/OPERATION_JOURNAL.md"},
+    {"source":"core/process/PROJECT_REQUIREMENTS_EXPORT.md","destination":"docs/process/PROJECT_REQUIREMENTS_EXPORT.md"},
+    {"source":"core/process/APPLICATION_VERSIONING.md","destination":"docs/process/APPLICATION_VERSIONING.md"},
     {"source":"core/templates/PULL_REQUEST_TEMPLATE.md","destination":".github/PULL_REQUEST_TEMPLATE.md"},
     {"source":"core/templates/PRODUCT_BRIEF_TEMPLATE.md","destination":"docs/templates/PRODUCT_BRIEF_TEMPLATE.md"},
     {"source":"core/templates/FEATURE_BRIEF_TEMPLATE.md","destination":"docs/templates/FEATURE_BRIEF_TEMPLATE.md"},

package/assets/generated/ASSEMBLY.json

@@ -1,12 +1,12 @@
 {
   "schemaVersion": 1,
   "package": "@mriekki/project-forge",
-  "version": "2.0.0",
+  "version": "2.1.0",
   "components": {
     "core": {
       "repository": "mriekki/project-forge-core",
-      "commit": "80ff581ec89533f5a22bd05c65c7b67bb314c715",
-      "version": "3.0.0",
+      "commit": "fd071b9516cb40093f30be41ab695139eb16bb4c",
+      "version": "3.3.0",
       "distribution": "greenfield-workspace",
       "files": [
         {
@@ -64,6 +64,26 @@
           "destination": ".github/skills/setup/SKILL.md",
           "sha256": "e700e914afc291ffb1153bb796a8ef150c624c5b54032e29d3abda221260285f"
         },
+        {
+          "source": "core/skills/build/SKILL.md",
+          "destination": ".github/skills/build/SKILL.md",
+          "sha256": "0659ad88cac5ca652eedba648d10a39ca1d51d65db638ce41b392067a3fd6128"
+        },
+        {
+          "source": "core/skills/run/SKILL.md",
+          "destination": ".github/skills/run/SKILL.md",
+          "sha256": "6bdf23f46609d1b85147347d313d7c4bf13bd8bfc91d4b782fc7a311189ffbe3"
+        },
+        {
+          "source": "core/skills/export-requirements/SKILL.md",
+          "destination": ".github/skills/export-requirements/SKILL.md",
+          "sha256": "6ef2675eafdbcc809f6fb9533ab41ff032a1f3ff4789b1d5825d27cf696d0715"
+        },
+        {
+          "source": "core/skills/replatform/SKILL.md",
+          "destination": ".github/skills/replatform/SKILL.md",
+          "sha256": "86e17bf376f395e5f5f018d8def7f5d99b9f4baef30c0b1d20f5caaac5c993c8"
+        },
         {
           "source": "core/skills/progress/SKILL.md",
           "destination": ".github/skills/progress/SKILL.md",
@@ -219,6 +239,21 @@
           "destination": "docs/process/SETUP_ACCEPTANCE_CHECKLIST.md",
           "sha256": "b5f8b39de15b464a1c80b26a6c150c6d2a363751abc05d33df4cebcad6b49d9b"
         },
+        {
+          "source": "core/process/OPERATION_JOURNAL.md",
+          "destination": "docs/process/OPERATION_JOURNAL.md",
+          "sha256": "16e2d502d7b0f923b4ea2e34bdcaaed73cdc0933fd6ef54a1278dd25f25b5140"
+        },
+        {
+          "source": "core/process/PROJECT_REQUIREMENTS_EXPORT.md",
+          "destination": "docs/process/PROJECT_REQUIREMENTS_EXPORT.md",
+          "sha256": "6ef9ecf1bb7c86b5f445554f5e630db36beee34bead2db8ff2597c148fba9c30"
+        },
+        {
+          "source": "core/process/APPLICATION_VERSIONING.md",
+          "destination": "docs/process/APPLICATION_VERSIONING.md",
+          "sha256": "846abd1085501bebf3ffd8025f875dcf2bfb3f57e67110e684c605ae11c3246b"
+        },
         {
           "source": "core/templates/PULL_REQUEST_TEMPLATE.md",
           "destination": ".github/PULL_REQUEST_TEMPLATE.md",

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

@@ -0,0 +1,137 @@
+# Project Forge Application Versioning
+
+Every Project Forge application must implement a real runtime version identity. A static label that never changes across builds is not sufficient.
+
+## Contract
+
+Application versioning has two layers:
+
+1. **release version** — a deliberate Semantic Version such as `0.1.0` or `1.0.0`;
+2. **build identity** — automatically derived evidence that identifies the exact built artifact.
+
+The normal human-readable form is intentionally simple:
+
+```text
+v1.0.0 (build 142)
+```
+
+The machine/informational form may carry richer provenance:
+
+```text
+1.0.0+build.142.sha.a1b2c3d
+```
+
+A build record should expose equivalent fields when available:
+
+```text
+releaseVersion: 1.0.0
+buildNumber: 142
+commit: a1b2c3d
+builtAtUtc: 2026-10-21T20:15:00Z
+informationalVersion: 1.0.0+build.142.sha.a1b2c3d
+displayVersion: v1.0.0 (build 142)
+```
+
+## Release version
+
+Use Semantic Versioning (`MAJOR.MINOR.PATCH`) for the application release version.
+
+Recommended default for a new project under active development:
+
+```text
+0.1.0
+```
+
+Promote deliberately. The first accepted V1 release may become `1.0.0`; later major/minor/patch changes follow the project's release policy.
+
+The release version is expected to remain stable across multiple development builds. It must not be bumped merely to create a unique build identity.
+
+Use one stack-native authoritative source for the release version. Do not maintain unrelated duplicated constants or decorative `VERSION.md` values that can drift from the built application.
+
+## Build identity
+
+A releasable CI-built artifact must receive an automatically derived build identity.
+
+Preferred evidence:
+
+- monotonically increasing CI/build sequence number;
+- exact source commit, with a short commit acceptable for display and the full commit retained in machine evidence when practical;
+- UTC build timestamp as supplemental evidence.
+
+The canonical informational form is conceptually:
+
+```text
+<releaseVersion>+build.<buildNumber>.sha.<shortCommit>
+```
+
+A timestamp may be appended as metadata, but a date alone should not replace a sequencing value when the build system can provide a monotonic run/build number.
+
+For local developer builds where no CI build number exists, use an explicitly non-release identity such as:
+
+```text
+0.1.0+local.20261021T201500Z.sha.a1b2c3d
+```
+
+Do not invent a CI/release build number for a local build.
+
+## Runtime exposure
+
+The running application must make its effective version identity observable.
+
+For applications with a user interface, expose a concise human-readable value in an appropriate low-noise surface such as About, Settings, diagnostics, or a footer:
+
+```text
+v1.0.0 (build 142)
+```
+
+Also provide machine-readable or diagnostic evidence when the stack/application shape supports it, for example:
+
+- a version/info endpoint;
+- CLI `--version` output;
+- startup diagnostic metadata;
+- an application metadata object consumed by the UI.
+
+The display must be derived from the same build identity as the machine evidence rather than maintained as a separate hard-coded string.
+
+## Stack-specific implementation
+
+The contract is stack-independent; the implementation is not.
+
+Examples of appropriate stack-native sources include:
+
+- .NET/Blazor/ASP.NET: project/package version plus assembly/informational version metadata;
+- Node/React/Angular: package/project version plus build-time injected CI/commit metadata;
+- Java/Spring: Maven/Gradle project version plus generated build metadata/resources.
+
+These examples are implementation guidance, not a fixed technology requirement. Prefer the repository's native build/package mechanism.
+
+## Build and run helpers
+
+`/build` should report the effective release/build identity when the selected build produces or exposes it.
+
+`/run` should report the effective runtime version when the started application exposes it.
+
+Neither helper should invent version information or mutate release version state merely to make version evidence appear.
+
+## Delivery and deployment
+
+A deployable artifact should be traceable to one version identity and one source commit. Deployment evidence may record the version/build identity, but deployment must not silently rewrite it.
+
+A release tag, GitHub release, package version, container tag, or deployment label does not substitute for runtime application version evidence unless the built application actually consumes that same authoritative version metadata.
+
+## Replatforming
+
+Application versioning is a reusable engineering requirement, not a portable product requirement.
+
+`PROJECT_REQUIREMENTS.json` therefore does not need to encode stack-specific version mechanics. A replatformed project must receive the current Project Forge application-versioning contract and implement it using the target stack's native facilities.
+
+## Acceptance
+
+Application foundation is not complete until:
+
+- one authoritative release version source exists;
+- a build can derive a unique build identity without manually editing display text;
+- the source commit is traceable from build evidence;
+- a running application exposes the effective version in an appropriate human-readable form;
+- release/CI builds use a real sequencing value when the CI system provides one;
+- local builds are clearly distinguishable from release/CI builds.

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

@@ -0,0 +1,140 @@
+# Project Forge Operation Journal
+
+Project Forge uses local operation journals to preserve durable, workstation-local evidence for consequential deterministic operations without turning normal read-only guidance into noisy state.
+
+## Purpose
+
+An operation journal answers:
+
+- what deterministic operation ran;
+- when it started and finished;
+- which workspace/platform/provenance it used;
+- which bounded steps ran and their outcomes;
+- where a failure occurred;
+- what final status was reached.
+
+The journal is diagnostic evidence. It is not a second workflow database and it does not replace Git, GitHub, CI, deployment state, or human acceptance.
+
+## Location
+
+Store local journals under the ignored Project Forge cache:
+
+```text
+.project-forge/
+  logs/
+    <operation>/
+      <timestamp>-<run-id>.log
+      latest.log
+```
+
+Examples:
+
+```text
+.project-forge/logs/setup/2026-10-20T190523-0700-18432.log
+.project-forge/logs/build/...
+.project-forge/logs/run/...
+.project-forge/logs/project-forge-update/...
+.project-forge/logs/deployment-readiness/...
+.project-forge/logs/deploy/...
+.project-forge/logs/tear-down/...
+```
+
+`latest.log` may be a copied summary/current run for convenience. Implementations must not depend on symlink support.
+
+Operation journals are workstation-local and must remain ignored by Git. They are never part of `CORE_BASELINE.json`, `PROJECT_FORGE_BASELINE.json`, or application provenance.
+
+## Operations that should journal
+
+Journal deterministic operations when durable local diagnostics materially help:
+
+- `/setup` and repository-local setup/doctor execution;
+- `/build` when build diagnostics/artifact evidence are useful;
+- `/run` as a concise startup/health receipt when useful, not as an unbounded application log sink;
+- `/project-forge-update` apply/verification work;
+- `/developer-env-mode` when it mutates or converges local runtime state;
+- `/deployment-readiness` when it performs preparation or repair;
+- environment proof operations;
+- `/deploy` and `/tear-down`;
+- other bounded deterministic operations that mutate workstation or remote environment state.
+
+`/deliver` may write a concise local receipt, but Git commits, PRs, CI, and merge history remain its authoritative durable evidence.
+
+Read-only orientation normally does **not** create a journal:
+
+- `/progress`;
+- `/next-step`;
+- `/wait-what`;
+- read-only documentation/learning navigation;
+- read-only status checks unless a caller explicitly requests troubleshooting evidence.
+
+Remote GitHub Actions already retain their own workflow logs. Do not duplicate complete remote logs locally; record only the local request/provenance/result receipt when useful.
+
+## Minimum record
+
+A journal should capture, when available:
+
+```text
+operation
+run identifier
+started/finished timestamps
+workspace root or project identity
+platform/architecture
+relevant Project Forge/Core/Bootstrap/Deployment provenance
+step name
+step status
+resolved tool/version evidence
+sanitized command identity
+exit code
+sanitized failure summary
+final status
+```
+
+For `/build`, include the requested target and explicit artifact/output paths when the repository build contract establishes them.
+
+For `/run`, record only bounded startup evidence such as target, command identity, process/startup result, established local endpoint/health result, and stop guidance. Do not continuously tee long-running application output into the Project Forge journal.
+
+Prefer stable event names and compact machine-readable fields inside a human-readable `.log`. JSON Lines is acceptable when the implementation already uses structured events.
+
+At completion, report the journal path to the developer when the operation was consequential or when diagnostics were produced.
+
+## Security and privacy boundary
+
+Operation journals are diagnostic artifacts, not raw transcripts.
+
+Never log:
+
+- passwords, PATs, API keys, access tokens, private SSH keys, or secret values;
+- credential-manager contents;
+- full process environment dumps;
+- request/response bodies that may contain credentials;
+- arbitrary stdin or secure-prompt contents;
+- known-host private material or mutable application data merely for convenience.
+
+Prefer allowlisted structured fields over blind stdout/stderr capture.
+
+When command arguments or error text may contain secrets, redact before writing. Implementations should log a command identity such as executable + safe arguments, step name, return code, and a bounded sanitized failure summary rather than blindly teeing every subprocess byte.
+
+A local journal must not weaken an existing secure prompt, credential boundary, or Human-in-the-Loop gate.
+
+## Lifecycle
+
+For a mutating deterministic operation:
+
+1. create the journal before the first material mutation;
+2. record operation/provenance preflight;
+3. append bounded step outcomes as work proceeds;
+4. flush useful failure evidence before returning/raising;
+5. record one final state such as `READY`, `SUCCESS`, `DEFERRED`, `BLOCKED`, `FAILED`, or a domain-specific equivalent;
+6. refresh `latest.log` only after the run has a coherent record.
+
+A failed operation keeps its timestamped journal. Do not erase failure evidence merely because a later retry succeeds.
+
+## Retention
+
+Journals are disposable local diagnostics. Project Forge may prune old logs using a conservative size/count policy, but must preserve the current run while it is active and should retain enough recent history to diagnose repeated failures.
+
+Do not silently upload operation journals to GitHub, ChatGPT, telemetry, or another machine. A developer may explicitly choose to share a relevant sanitized excerpt when troubleshooting.
+
+## Relationship to human acceptance
+
+A successful journal entry is machine evidence only. It never marks editor/workspace acceptance, meaningful-diff acceptance, merge authorization, release publication, or production deployment approval on the human's behalf.

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

@@ -0,0 +1,165 @@
+# Project Requirements Export
+
+`PROJECT_REQUIREMENTS.json` is the canonical portable Project Forge interchange artifact for durable product, domain, experience, roadmap, and approved cross-cutting intent.
+
+It exists to support workflows such as replatforming the same product onto a different implementation stack without treating the source repository's framework/tool choices as product requirements.
+
+## Authority
+
+The JSON file is a **derived export**, not a competing source of truth.
+
+Repository authorities continue to own their facts. In a normal generated workspace that commonly means:
+
+```text
+docs/product/PRODUCT_BRIEF.md
+→ docs/work-items/<FB-...>/brief.md
+→ approved requirements.md when present
+```
+
+Additional product/domain authorities may include roadmap, system-design/domain invariants, product-level design/accessibility guidance, accepted ADR consequences, and project-owned decisions.
+
+The export must retain source paths/authority/provenance so a consumer can trace normalized facts back to their repository authorities.
+
+## Canonical filename and state
+
+Only this filename is canonical:
+
+```text
+PROJECT_REQUIREMENTS.json
+```
+
+The contract has no compatibility alias or alternate export filename.
+
+State is explicit:
+
+```text
+draft
+review
+approved
+```
+
+Only `approved` may be consumed as replatform input.
+
+## Portable content model
+
+The export should represent, when present:
+
+- project/product identity;
+- problem, users/stakeholders, desired outcomes, scope/non-scope;
+- product workflows/capabilities and success measures;
+- Feature Briefs with source ID, title, target milestone, target disposition, authority/status/maturity, outcomes, scope/non-scope, workflows, business/domain rules, dependencies, acceptance criteria, learning objectives, and open questions;
+- domain concepts and relationships;
+- domain invariants, lifecycle/state semantics, and business rules;
+- cross-cutting security/privacy, accessibility, reliability, performance, and data requirements;
+- portable product/UX principles, responsive constraints, and interaction intent;
+- roadmap milestones/sequencing facts that express product intent;
+- accepted decisions whose consequences are portable;
+- explicit learning intent/future ideas while preserving their non-authorizing maturity;
+- exact source repository/commit and contributing artifact paths.
+
+## Product Brief model
+
+Project Forge generated workspaces currently use one canonical product authority:
+
+```text
+docs/product/PRODUCT_BRIEF.md
+```
+
+The export therefore uses one normalized `product` object rather than inventing a multi-Product-Brief hierarchy.
+
+If a non-generated/adopted workspace declares a different authority model, export only what that model actually establishes. Do not manufacture a second Product Brief merely to fit Project Forge defaults.
+
+## Work-item maturity
+
+Preserve maturity exactly.
+
+Typical generated-project semantics include:
+
+```text
+V1 + committed
+V2 + planned
+V3 + directional
+```
+
+Presence in `PROJECT_REQUIREMENTS.json` is never implementation authorization. A roadmap Feature remains roadmap/directional until separately promoted through the normal requirements/work-item process.
+
+## Engineering Enablers
+
+Engineering Enablers are usually implementation-specific and are not portable product requirements.
+
+The export may retain an enabler in source traceability when it establishes a durable cross-cutting requirement, but replatforming normally re-derives stack-specific enablers rather than copying their IDs/scope.
+
+Examples:
+
+```text
+PRESERVE: secure individual authentication is required for remote internet use
+RE-DERIVE: configure ASP.NET authentication middleware
+
+PRESERVE: database schema changes must be reproducible and controlled
+RE-DERIVE: use EF Core migrations
+```
+
+## Mixed authorities
+
+Some documents mix durable intent with implementation choices. Treat these as classification inputs rather than all-or-nothing copies.
+
+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;
+- 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.
+
+## Exclusions
+
+Do not export as portable requirements unless the repository explicitly makes them true product constraints:
+
+- programming languages/frameworks/component libraries;
+- ORMs, package managers, build tools, test runners;
+- repository/project directory layouts;
+- generated client/tooling mechanisms;
+- CI implementation commands;
+- current deployment host/provider bindings;
+- secrets/credentials/private runtime values;
+- application source code;
+- work-item plans/review/delivery history;
+- Git/PR/CI evidence;
+- Project Forge/Core/Bootstrap baseline state.
+
+## Replatform relationship
+
+The canonical flow is:
+
+```text
+project authorities
+→ /export-requirements
+→ PROJECT_REQUIREMENTS.json state=review
+→ human approval
+→ PROJECT_REQUIREMENTS.json state=approved
+→ /replatform <target-stack>
+→ current Bootstrap catalog reconciliation
+→ PROJECT_BOOTSTRAP.json state=review
+→ human Bootstrap approval
+→ deterministic generation into a new repository
+```
+
+`PROJECT_BOOTSTRAP.json` remains the generation/provenance contract for one implementation. `PROJECT_REQUIREMENTS.json` remains the portable product/domain interchange contract.
+
+## No in-place replatforming
+
+Replatforming creates a sibling/new implementation repository. It never rewrites the source application in place.
+
+This preserves historical truth and allows multiple implementations of the same product intent to coexist, such as:
+
+```text
+Family Meal Planner requirements
+├── React + ASP.NET Core implementation
+├── Angular + Spring Boot implementation
+└── Blazor + ASP.NET Core implementation
+```
+
+## Security
+
+The export must not contain secrets, credentials, private keys, access tokens, production data, machine-local bindings, or arbitrary runtime/log transcripts.

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

@@ -0,0 +1,70 @@
+---
+name: build
+description: "Build the current project through its repository-owned build command without turning local compilation into setup, testing, delivery, or deployment."
+argument-hint: "[target|all]"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Build
+
+`/build` is a thin local helper. It hides framework-specific command details while preserving the repository as the authority for how the project builds.
+
+## Contract
+
+Invoking `/build` authorizes one bounded local build attempt for the requested target. It does not authorize setup, dependency upgrades, source edits, delivery, release publication, deployment, or Production access.
+
+Resolve the build command from current repository evidence in this order:
+
+1. an explicit repository-owned build wrapper or documented build command;
+2. an explicit package/task script whose purpose is build;
+3. an unambiguous ecosystem-native build entry point already present in the repository.
+
+Do not invent a command because a framework is recognizable. If multiple materially different build targets exist and no default is documented, require a target such as `/build web`, `/build api`, or `/build all`.
+
+## Preconditions
+
+Before execution:
+
+- identify the repository root and current Git state;
+- inspect `PROJECT_BOOTSTRAP.json` and scaffold/readiness evidence when present;
+- verify that the selected build entry point exists;
+- do not create an intentionally deferred scaffold merely to make `/build` succeed.
+
+If the approved scaffold is deferred or required build markers do not exist, return `BUILD NOT AVAILABLE` with the smallest relevant reason. Do not run installation/scaffolding commands as an implicit repair.
+
+If dependencies or workstation tools are missing, recommend `/setup` rather than broadening `/build`.
+
+## Execution
+
+Run the selected build visibly and report:
+
+- target;
+- resolved repository-owned command identity;
+- success/failure and exit code when available;
+- produced artifact/output locations when the build contract makes them explicit;
+- effective application release/build identity when the build exposes it;
+- a concise actionable failure summary.
+
+Do not add linting, tests, formatting, packaging, container publishing, or code generation unless the repository's selected build command already defines them as part of that build.
+
+When the project implements `docs/process/APPLICATION_VERSIONING.md`, report observed version evidence from the build output/artifact metadata. Do not synthesize a build number, commit, or display version when the repository did not produce it.
+
+## Operation journal
+
+A consequential build may write a concise sanitized journal under `.project-forge/logs/build/` following `docs/process/OPERATION_JOURNAL.md`.
+
+Record the command identity, target, timestamps, exit status, explicit artifact paths, and observed application version/build identity when available. Do not blindly capture unlimited compiler/application output or secrets.
+
+## Git and lifecycle boundary
+
+`/build` must not:
+
+- edit source or configuration to fix a build;
+- stage, commit, push, open/update PRs, merge, or clean branches;
+- mark a work item accepted or delivered;
+- bump the application's release version merely to create a unique build;
+- publish a package/image/release;
+- deploy locally or remotely.
+
+A successful build is local machine evidence only.

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

@@ -0,0 +1,132 @@
+---
+name: export-requirements
+description: "Export the workspace's durable product, domain, UX, roadmap, and approved feature intent into canonical PROJECT_REQUIREMENTS.json without copying stack-specific implementation choices."
+argument-hint: "[review|approve]"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Export Project Requirements
+
+`/export-requirements` creates the portable Project Forge requirements interchange artifact:
+
+```text
+PROJECT_REQUIREMENTS.json
+```
+
+It is a derived export of the workspace's existing authorities. It is not a competing requirements database and it never outranks the source Product Brief, Feature Briefs, approved detailed requirements, accepted product/domain decisions, or other repository authorities.
+
+## Purpose
+
+Use this export when the same product/system intent should be carried into a new implementation, especially `/replatform`.
+
+The export answers:
+
+> What must remain true about the product, domain, user experience, roadmap, and accepted cross-cutting behavior independent of this implementation stack?
+
+It must not answer:
+
+> Which framework, language, ORM, build tool, folder layout, or CI implementation should the next repository use?
+
+## Source model
+
+Start from the workspace's declared authority model. In a normal generated Project Forge workspace, inspect as applicable:
+
+1. `docs/product/PRODUCT_BRIEF.md` as product authority;
+2. `docs/product/IMPLEMENTATION_ROADMAP.md` for milestone/feature maturity and product sequencing facts;
+3. Product Feature folders under `docs/work-items/`, including `brief.md` and approved `requirements.md`;
+4. product/domain portions of architecture or system-design documents;
+5. durable domain concepts, relationships, invariants, and business rules;
+6. product-level design principles, accessibility/responsive requirements, and relevant interaction patterns;
+7. accepted ADRs/decisions that constrain product/domain behavior;
+8. approved cross-cutting security/privacy, reliability, performance, and data requirements;
+9. learning goals/future ideas when they are explicitly part of project intent, preserving their non-authorizing status.
+
+Treat summaries such as AI context briefs as reference/navigation unless the repository declares them authoritative.
+
+## Preserve authority and maturity
+
+Do not flatten roadmap maturity.
+
+Preserve distinctions such as:
+
+```text
+V1 / committed / approved
+V2 / planned / roadmap
+V3 / directional / roadmap
+```
+
+A directional Feature remains directional in the export. Exporting it must not promote it into implementation scope.
+
+## Classification
+
+Classify source material before export.
+
+### Preserve
+
+Normally portable:
+
+- product problem, goals, users, outcomes, scope/non-scope;
+- Feature Brief intent and product dependencies;
+- approved functional/domain requirements and acceptance criteria;
+- domain concepts, relationships, invariants, lifecycle/state semantics, business rules;
+- security/privacy outcomes and constraints;
+- accessibility/responsive/product-experience requirements;
+- product-level design principles and interaction intent;
+- milestone/roadmap target and maturity;
+- learning intent when explicitly part of the project.
+
+### Reconcile
+
+Require human review when a durable requirement is mixed with implementation detail, for example:
+
+- API/persistence semantics expressed using a current framework;
+- architecture documents containing both domain invariants and technology topology;
+- ADRs that combine product consequences with stack choices;
+- UX patterns containing both user behavior and component-library detail.
+
+Preserve the durable intent and exclude/rephrase the implementation-specific mechanism.
+
+### Exclude / re-derive
+
+Do not export as portable requirements:
+
+- React, Angular, Blazor, Java, C#, Spring Boot, ASP.NET Core, ORM, package-manager, or build-tool choices unless they are explicitly approved product constraints;
+- source directory/project layout;
+- framework/component-library implementation details;
+- stack-specific Engineering Enablers;
+- CI implementation commands;
+- deployment scripts/bindings/credentials;
+- implementation plans, code, review history, branch/PR/CI evidence;
+- generated Project Forge/Core provenance.
+
+## Artifact state and human gate
+
+Default `/export-requirements` writes or refreshes `PROJECT_REQUIREMENTS.json` with `state: "review"` and exact source repository/commit provenance.
+
+Before calling it approved, present a compact reconciliation summary:
+
+```text
+PROJECT REQUIREMENTS EXPORT
+
+Preserved product/features: ...
+Preserved domain rules: ...
+Preserved UX/cross-cutting constraints: ...
+Roadmap maturity retained: ...
+Implementation-specific material excluded: ...
+Items requiring reconciliation: ...
+
+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.
+
+## Safety and scope
+
+The skill may create/update only `PROJECT_REQUIREMENTS.json` unless the human separately authorizes source-document edits.
+
+It must not silently rewrite source Product/Feature Briefs, requirements, architecture, ADRs, roadmap, or design documents to make export easier.
+
+Do not export secrets, credentials, production values, personal runtime data, or machine-local bindings.

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

@@ -0,0 +1,122 @@
+---
+name: replatform
+description: "Create a new implementation proposal from approved PROJECT_REQUIREMENTS.json and a requested target stack without rewriting the source project in place."
+argument-hint: "<target-stack-or-recipe>"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Replatform
+
+`/replatform` creates a new implementation proposal for the same product/system intent using a different technology stack.
+
+It never rewrites the source application in place.
+
+## Required input
+
+Use only the canonical portable export:
+
+```text
+PROJECT_REQUIREMENTS.json
+```
+
+The file must be `state: "approved"`. Do not accept alternate/legacy requirements-export filenames or infer approval from file existence.
+
+If the export is missing or stale relative to material source-requirement changes, use `/export-requirements` first.
+
+## Target
+
+The invocation supplies a target stack or current Bootstrap recipe, for example:
+
+```text
+/replatform angular java
+/replatform java-angular-sqlite
+/replatform blazor sqlite
+```
+
+Resolve support against the current canonical Project Forge Bootstrap catalog. General model knowledge may explain an uncataloged technology, but label it `CATALOG GAP` and do not fabricate Bootstrap automation/support.
+
+## Output boundary
+
+The operation produces a new `PROJECT_BOOTSTRAP.json` proposal with `state: "review"` for a new target repository.
+
+It must record derivation provenance back to the approved requirements export/source repository and identify the selected current Bootstrap catalog/protocol and Project Forge package provenance.
+
+Do not generate application source or mutate the target repository until the normal Bootstrap manifest review/approval gate is complete.
+
+## Reconciliation rules
+
+Preserve from the approved requirements export:
+
+- product problem/goals/users/outcomes;
+- Product Feature intent and target maturity;
+- approved functional/domain requirements and acceptance criteria;
+- domain concepts, relationships, invariants, lifecycle/state semantics, and business rules;
+- portable security/privacy/reliability/data constraints;
+- portable design, accessibility, responsive, and interaction intent;
+- roadmap maturity (`committed`, `planned`, `directional`);
+- explicitly preserved learning intent.
+
+Re-derive for the requested stack:
+
+- Engineering Enablers;
+- framework/application shell work;
+- implementation architecture/topology;
+- persistence/ORM implementation;
+- API/client implementation choices;
+- build/run/test commands and package tooling;
+- stack-specific ADRs;
+- CI implementation details;
+- deployment mechanics that depend on the new architecture.
+
+Do not automatically preserve source Engineering Enabler IDs. Product Feature IDs may remain traceable when the semantic Feature is unchanged; record source IDs even when the new implementation re-slices or renumbers work.
+
+## New-repository rule
+
+Replatforming requires a new target repository identity. The source repository is read-only evidence.
+
+Never:
+
+- overwrite the source repository;
+- replace its `PROJECT_BOOTSTRAP.json`;
+- delete or rewrite source implementation history;
+- copy source application code by default;
+- copy secrets, production data, credentials, machine bindings, or execution evidence.
+
+## Bootstrap execution
+
+Use the current canonical Bootstrap replatform tooling when available. The expected deterministic boundary is:
+
+```text
+approved PROJECT_REQUIREMENTS.json
++ requested current catalog recipe/stack
++ target repository identity
+→ PROJECT_BOOTSTRAP.json state=review
+```
+
+If canonical Bootstrap replatform tooling/current catalog evidence is unavailable in the current environment, stop with `REPLATFORM HANDOFF REQUIRED`. Do not invent a manifest from stale remembered catalog facts.
+
+## Human gate
+
+Before generation, summarize at minimum:
+
+```text
+SOURCE REQUIREMENTS
+source repository/commit
+portable requirements export provenance
+
+PRESERVED
+product/features/domain/UX/cross-cutting intent
+roadmap maturity
+
+RE-DERIVED
+stack-specific architecture and Engineering Enablers
+
+TARGET STACK
+resolved current catalog recipe and support state
+
+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.

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

@@ -0,0 +1,75 @@
+---
+name: run
+description: "Run the current project locally through its repository-owned runtime command without conflating local execution with deployment."
+argument-hint: "[target|all]"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Run
+
+`/run` is the normal convenience entry point for starting the project locally. It resolves and delegates to repository-owned runtime commands rather than requiring the developer to remember framework-specific launch syntax.
+
+## Contract
+
+Invoking `/run` authorizes one bounded local start attempt for the requested target. It does not authorize setup, source edits, deployment, release publication, Production access, or persistent background services outside the repository's normal local-development contract.
+
+Resolve the local runtime command from current repository evidence in this order:
+
+1. an explicit repository-owned run/dev wrapper or documented command;
+2. an explicit package/task script whose purpose is local run/dev;
+3. an unambiguous ecosystem-native local entry point already present in the repository.
+
+Do not guess. If the repository has multiple independent runtimes and no documented default, require a target such as `/run web`, `/run api`, or `/run all`.
+
+## Preconditions
+
+Before starting:
+
+- identify repository root and current Git state;
+- inspect `PROJECT_BOOTSTRAP.json` and scaffold/readiness evidence when present;
+- verify the selected runtime entry point exists;
+- inspect any documented local ports/health endpoints;
+- do not create an intentionally deferred scaffold merely to make `/run` succeed.
+
+If runtime source is intentionally deferred or absent, return `RUN NOT AVAILABLE` and identify the owning work item or missing marker when repository evidence provides it.
+
+If workstation tools or dependencies are missing, recommend `/setup` instead of silently installing them.
+
+## Execution
+
+Start the process in an observable developer-controlled terminal/process surface. Do not hide a long-running application in an unexplained background process.
+
+Report:
+
+- target;
+- resolved command identity;
+- process/startup result;
+- effective application release/build identity when the running application exposes it;
+- local URL/port or health evidence only when repository/runtime evidence establishes it;
+- how to stop the process.
+
+When `/run all` is explicitly supported, start only the repository-defined set of local components and make each process/endpoint visible.
+
+When the project implements `docs/process/APPLICATION_VERSIONING.md`, prefer runtime-observed version evidence over a source-file guess. Do not synthesize a build number or claim that a static source label proves the running artifact's identity.
+
+## Operation journal
+
+`/run` may write a concise sanitized startup receipt under `.project-forge/logs/run/` following `docs/process/OPERATION_JOURNAL.md`.
+
+Record startup command identity, target, timestamps, startup/health result, observed application version/build identity, and endpoint when established. Do not duplicate or continuously capture unbounded application stdout/stderr into the Project Forge journal.
+
+## Deployment boundary
+
+`/run` is not `/deploy local`.
+
+It must not:
+
+- mutate remote environments;
+- publish images/packages/releases;
+- change deployment bindings;
+- infer Production configuration;
+- bump or rewrite release version state;
+- stage, commit, push, merge, or clean branches.
+
+A successful `/run` proves only that the requested local runtime started with the evidence observed in that session.

package/package.json

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