@mriekki/project-forge 1.0.0 → 2.1.0

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/deploy/SKILL.md

@@ -27,7 +27,7 @@ Prefer:
 DEPLOYMENT_TOPOLOGY.json
 ```
 
-Use `POC_BOOTSTRAP.json` deployment topology only as the initial topology fallback.
+Use `PROJECT_BOOTSTRAP.json` deployment topology only as the initial topology fallback.
 
 Resolve exact configured name, purpose/Production classification, placement, isolation, exposure, binding, adapter, target/provider, and failure domain.
 

package/assets/generated/core/core/skills/deployment-readiness/SKILL.md

@@ -29,7 +29,7 @@ Prefer the project-owned mutable topology:
 DEPLOYMENT_TOPOLOGY.json
 ```
 
-Use `POC_BOOTSTRAP.json` deployment topology only as the initial topology fallback. Do not rewrite Bootstrap provenance merely because a later environment changes.
+Use `PROJECT_BOOTSTRAP.json` deployment topology only as the initial topology fallback. Do not rewrite Bootstrap provenance merely because a later environment changes.
 
 Resolve the exact configured environment name plus, when present:
 

package/assets/generated/core/core/skills/developer-env-mode/SKILL.md

@@ -31,7 +31,7 @@ Never record a requested mode as ready until its readiness contract passes. If c
 
 From the repository root inspect, when present:
 
-- `POC_BOOTSTRAP.json`;
+- `PROJECT_BOOTSTRAP.json`;
 - `PROJECT_FORGE_BASELINE.json` and component baselines;
 - `DEV_ENVIRONMENT.json`;
 - application setup/build/test commands and project-owned persistence configuration;

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/progress/SKILL.md

@@ -16,7 +16,7 @@ Invocation is read-only. `/progress` is a navigation/status surface, not a secon
 
 Inspect only the evidence needed for the current lifecycle position. Useful sources include:
 
-- `POC_BOOTSTRAP.json`, generated baselines, and repository history for project creation/provenance;
+- `PROJECT_BOOTSTRAP.json`, generated baselines, and repository history for project creation/provenance;
 - `DEPLOYMENT_TOPOLOGY.json` as preferred project-owned mutable environment topology when present;
 - `DEV_ENVIRONMENT.json`, generated setup scripts, workstation-local setup/developer-mode evidence, and safe setup checks for local readiness;
 - observed OS/platform and machine-local evidence for **this workspace instance**;
@@ -24,7 +24,7 @@ Inspect only the evidence needed for the current lifecycle position. Useful sour
 - work-item docs, Reviewer evidence, PR/CI state, and default-branch evidence;
 - environment proof/readiness/deployment evidence for exact project-defined environments.
 
-If `DEPLOYMENT_TOPOLOGY.json` does not exist, use `POC_BOOTSTRAP.json` deployment topology only as the initial topology fallback.
+If `DEPLOYMENT_TOPOLOGY.json` does not exist, use `PROJECT_BOOTSTRAP.json` deployment topology only as the initial topology fallback.
 
 Never invent completion because a prior step normally happens. Prefer `UNKNOWN`/`NOT EVIDENCED` over false green state.
 

package/assets/generated/core/core/skills/project-forge-update/SKILL.md

@@ -30,7 +30,7 @@ From the consumer root read:
 - `PROJECT_FORGE_BASELINE.json`;
 - `CORE_BASELINE.json` when present;
 - `DEPLOYMENT_BASELINE.json` when present;
-- `POC_BOOTSTRAP.json` when present;
+- `PROJECT_BOOTSTRAP.json` when present;
 - current Git status, branch, remotes, and default branch when observable.
 
 Require `PROJECT_FORGE_BASELINE.json` to identify:
@@ -47,13 +47,13 @@ Do not synthesize or repair missing umbrella provenance by hand.
 
 ### Bootstrap-generated consumers
 
-If `POC_BOOTSTRAP.json` exists, treat it as approved generated-consumer provenance, not unrelated product data.
+If `PROJECT_BOOTSTRAP.json` exists, treat it as approved generated-consumer provenance, not unrelated product data.
 
 Before planning an update, require `generation.projectForge.package`, `generation.projectForge.version`, and `generation.projectForge.profile` to agree exactly with the installed `PROJECT_FORGE_BASELINE.json`. Require `generation.projectForge.integrity` to be a non-empty exact registry integrity value for that installed package/version. Verify that integrity read-only from the registry when registry access is available.
 
 If those values disagree before the update, report `GENERATED PROJECT FORGE METADATA DRIFT` and stop. Do not use `/project-forge-update` to silently reconcile an already-incoherent generated consumer.
 
-Also inspect generated package-verification surfaces such as `.github/workflows/ci.yml` when present. If they duplicate the approved package version/integrity literally, record that current shape as companion generated metadata that must remain coherent with `POC_BOOTSTRAP.json` during the update. Do not rewrite locally customized or unrecognized generated surfaces by guesswork.
+Also inspect generated package-verification surfaces such as `.github/workflows/ci.yml` when present. If they duplicate the approved package version/integrity literally, record that current shape as companion generated metadata that must remain coherent with `PROJECT_BOOTSTRAP.json` during the update. Do not rewrite locally customized or unrecognized generated surfaces by guesswork.
 
 ## 2. Verify the installed package baseline first
 
@@ -117,8 +117,8 @@ A modified retired Core path is different: never auto-add `--accept-retired core
 
 For a Bootstrap-generated consumer, also preview the companion generated-consumer changes:
 
-- `POC_BOOTSTRAP.json` keeps the same package/profile but changes `generation.projectForge.version` and `generation.projectForge.integrity` to the exact reviewed target;
-- generated package-verification surfaces should consume `POC_BOOTSTRAP.json` dynamically when the accepted Bootstrap contract supports that form;
+- `PROJECT_BOOTSTRAP.json` keeps the same package/profile but changes `generation.projectForge.version` and `generation.projectForge.integrity` to the exact reviewed target;
+- generated package-verification surfaces should consume `PROJECT_BOOTSTRAP.json` dynamically when the accepted Bootstrap contract supports that form;
 - a recognized older Bootstrap-generated verification block may be migrated only when its embedded old package/version/integrity exactly match the currently approved manifest metadata;
 - an unrecognized or locally modified generated verification surface is a stop condition, not permission to reconstruct Bootstrap output by hand.
 
@@ -148,7 +148,7 @@ Choosing option 1 authorizes only:
 - creation/switch to one repository-appropriate short-lived update branch when needed;
 - exact target package apply;
 - removal of unchanged retired package-managed files that the reviewed preview classified as `REMOVE`;
-- when `POC_BOOTSTRAP.json` is present, update of its exact `generation.projectForge.version` and `generation.projectForge.integrity` to the reviewed target while preserving package/profile;
+- when `PROJECT_BOOTSTRAP.json` is present, update of its exact `generation.projectForge.version` and `generation.projectForge.integrity` to the reviewed target while preserving package/profile;
 - migration of a recognized Bootstrap-generated package-verification block from duplicated current literals to the accepted manifest-driven form, only when the existing block still exactly matches the current approved metadata;
 - package/baseline/generated-consumer verification;
 - inspection of the resulting meaningful diff.
@@ -173,7 +173,7 @@ npx --yes @mriekki/project-forge@<target-version> update --apply
 
 If explicit Core retired-path ownership transfer was separately approved, pass only the exact reviewed modified paths using the package's `--accept-retired core:<path>` contract. Never widen that set implicitly. Unchanged retired managed paths do not need this flag; the package updater removes them according to the reviewed `REMOVE` plan.
 
-For a Bootstrap-generated consumer, complete the reviewed companion metadata changes in the same bounded update before declaring success. Preserve every unrelated `POC_BOOTSTRAP.json` field. Never change package identity or profile as an incidental version update.
+For a Bootstrap-generated consumer, complete the reviewed companion metadata changes in the same bounded update before declaring success. Preserve every unrelated `PROJECT_BOOTSTRAP.json` field. Never change package identity or profile as an incidental version update.
 
 Do not run direct `tools/package/sync.py`, Deployment Kit sync, or a remote `[sync-core]` request as part of a package-managed update.
 
@@ -190,7 +190,7 @@ Then inspect:
 ```text
 git status --short --branch
 git diff --stat
-git diff -- PROJECT_FORGE_BASELINE.json CORE_BASELINE.json DEPLOYMENT_BASELINE.json POC_BOOTSTRAP.json .github/workflows/ci.yml
+git diff -- PROJECT_FORGE_BASELINE.json CORE_BASELINE.json DEPLOYMENT_BASELINE.json PROJECT_BOOTSTRAP.json .github/workflows/ci.yml
 ```
 
 Confirm:
@@ -199,7 +199,7 @@ Confirm:
 - component baseline commits/distributions match the umbrella baseline;
 - package check passes for the whole profile;
 - unchanged retired managed files shown as `REMOVE` in the preview are actually absent after apply, while any explicitly transferred modified retired Core file remains present and is no longer Core-managed;
-- when `POC_BOOTSTRAP.json` exists, its package/version/profile agree with `PROJECT_FORGE_BASELINE.json` and its integrity equals the exact reviewed target registry integrity;
+- when `PROJECT_BOOTSTRAP.json` exists, its package/version/profile agree with `PROJECT_FORGE_BASELINE.json` and its integrity equals the exact reviewed target registry integrity;
 - when the repository contains `tools/project-forge-package/check-managed-baselines.py`, that generated baseline checker passes after all companion metadata changes;
 - generated package-verification surfaces no longer contradict the approved manifest metadata;
 - consumer-owned content was not overwritten;
@@ -218,7 +218,7 @@ Present the meaningful diff for human review. After acceptance, recommend `/deli
 - performs a downgrade/rollback as an ordinary update;
 - overwrites unexplained managed drift;
 - auto-accepts Core retired-path ownership transfer for a modified retired file;
-- silently repairs a pre-existing mismatch between `POC_BOOTSTRAP.json` and `PROJECT_FORGE_BASELINE.json`;
+- silently repairs a pre-existing mismatch between `PROJECT_BOOTSTRAP.json` and `PROJECT_FORGE_BASELINE.json`;
 - changes a generated consumer's package identity/profile or regenerates the repository as an incidental version update;
 - guesses at locally modified/unrecognized Bootstrap-generated verification logic;
 - publishes npm/Core/Deployment/Bootstrap releases or tags;

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.