create-forge 0.2.0__tar.gz → 0.3.0__tar.gz

{create_forge-0.2.0 → create_forge-0.3.0}/CHANGELOG.md

@@ -1,6 +1,54 @@
 # Changelog
 
 Generated by git-cliff from Conventional Commits.
+## [0.3.0] - 2026-09-05
+
+### Bug Fixes
+
+- Handle template clone failures
+
+### Documentation
+
+- Link canonical organisation policy model
+- Sync canonical Stage 09 contracts
+- Validate the reference-client boundary
+- Add Data Science CLI roadmap
+- Add Data Science CLI issue plan
+- Link canonical Data Science project shape
+- Link canonical Data Science capability contracts
+- Link production Jupyter capability
+- Link production Scientific Python capability
+- Record forge-template 0.4.0 release
+- Define generic component-selection CLI conventions (#122)
+
+### Features
+
+- Define the downstream policy-consumption hook (#97)
+- Add a downstream CLI integration reference (#98)
+- Add dry-run support to update
+- Prompt engine options from discovery, not the registry (#102)
+- Adopt the forge-template 0.4 compatibility line (#121)
+- Select capabilities and platforms from discovery (#123)
+- Collect options for every selected component (#124)
+
+### Testing
+
+- Validate the Data Science preview pipeline (#125)
+- Validate installed Data Science generation (#127)
+- Complete the rollout regression and failure matrix (#128)
+## [0.2.1] - 2026-08-31
+
+### Bug Fixes
+
+- Generate engine project lockfiles
+
+### Refactor
+
+- Derive component options from discovery, not an archetype list (#92)
+
+### Testing
+
+- Extend end-to-end generation to the public engine (#93)
 ## [0.2.0] - 2026-08-30
 
 ### Documentation
@@ -36,7 +84,7 @@ Generated by git-cliff from Conventional Commits.
 - Implement the shared create pipeline behind an opt-in engine flag (#83)
 - Stage and finalise generation without leaving partials (#84)
 - Expose the CLI Application archetype through the engine path (#89)
-- Publish to PyPI and assign the first bounded engine range
+- Publish to PyPI and assign the first bounded engine range (#90)
 
 ### Testing
 

{create_forge-0.2.0 → create_forge-0.3.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: create-forge
-Version: 0.2.0
+Version: 0.3.0
 Summary: Scaffold modern Python projects from maintained templates.
 Project-URL: Homepage, https://github.com/Sandsy09/create-forge
 Project-URL: Repository, https://github.com/Sandsy09/create-forge
@@ -26,7 +26,8 @@ Requires-Dist: questionary>=2.0
 Requires-Dist: rich>=13.9
 Requires-Dist: typer>=0.15
 Provides-Extra: engine
-Requires-Dist: forge-template<0.4,>=0.3.1; extra == 'engine'
+Requires-Dist: forge-template<0.5,>=0.4.1; extra == 'engine'
+Requires-Dist: uv<0.13,>=0.12; extra == 'engine'
 Description-Content-Type: text/markdown
 
 # create-forge
@@ -88,6 +89,9 @@ uvx create-forge new "My Lib" --yes \
   --data build_backend=hatchling \
   --data versioning=vcs \
   --data type_checking=both
+
+# Validate an update without changing project files
+uvx create-forge update --dry-run
 ```
 
 | Command | What it does |
@@ -101,6 +105,9 @@ uvx create-forge new "My Lib" --yes \
 Useful flags on `new`: `--template/-t`, `--path/-p`, `--data/-d`, `--yes/-y`,
 `--ref`, `--dry-run`.
 
+Useful flags on `update`: `--ref`, `--dry-run`. An update dry run validates the
+requested template update but does not apply it or produce a file-by-file diff.
+
 ## Configuration
 
 Optional. Saves retyping the same answers:
@@ -145,6 +152,27 @@ and [component manifest protocol v1](https://github.com/Sandsy09/forge-template/
 are now implemented behind the canonical
 [stable template-engine API](https://github.com/Sandsy09/forge-template/blob/main/docs/template-engine-api.md)
 ([ADR 0029](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0029-stable-template-engine-api.md)).
+The canonical
+[organisation-policy protocol v1](https://github.com/Sandsy09/forge-template/blob/main/docs/organisation-policy.md)
+defines how downstream clients resolve component-selection defaults and
+constraints before constructing that effective ProjectSpec. CF-09.01
+([ADR 0022](docs/adr/0022-downstream-organisation-policy-hook.md)) delivered
+the client-side consumption hook — this repository still resolves no policy
+itself; see the canonical
+[downstream policy-consumption contract](docs/organisation-policy-consumption.md).
+The canonical
+[safe extension contract](https://github.com/Sandsy09/forge-template/blob/main/docs/extension-points.md),
+[organisation-policy fixture](https://github.com/Sandsy09/forge-template/blob/main/docs/organisation-policy-fixtures.md),
+[compatibility policy](https://github.com/Sandsy09/forge-template/blob/main/docs/compatibility-policy.md),
+and [no-copy proof](https://github.com/Sandsy09/forge-template/blob/main/docs/no-copy-inheritance.md)
+complete forge-template's Stage 09 boundary. They deny arbitrary file
+replacement and prove that a client can retain policy/orchestration concerns
+without copying engine content or importing private engine modules. The
+decisions are recorded by forge-template
+[ADRs 0039](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0039-deny-policy-file-overrides.md),
+[0040](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0040-organisation-policy-reference-fixture.md),
+[0041](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0041-forge-blueprint-compatibility-policy.md),
+and [0042](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0042-validate-no-copy-downstream-inheritance.md).
 The accepted
 [Library archetype contract](https://github.com/Sandsy09/forge-template/blob/main/docs/library-archetype.md)
 defines the first production component, implemented on `forge-template/main`
@@ -158,13 +186,26 @@ it in the same `0.3.0` release, and
 archetypes behind the hidden `new --engine-preview` flag's `--archetype`
 option. Neither change alters this CLI's default `new` answers, registry, or
 released dependency surface.
+The Stage 08
+[composition architecture review](https://github.com/Sandsy09/forge-template/blob/main/docs/composition-architecture-review.md)
+is released in `forge-template 0.3.2`. On the engine-preview path,
+`create-forge 0.2.1` now finalises the validated in-memory render with
+`uv lock --directory <staging-directory>` before the atomic rename. The
+result contains `uv.lock` and uses `uv run --locked poe check`, while the
+default Copier path remains unchanged; see
+[ADR 0021](docs/adr/0021-client-finalises-engine-lockfiles.md).
 The engine now also defines in-memory
 [generated-project validation](https://github.com/Sandsy09/forge-template/blob/main/docs/generated-project-validation.md)
 ([ADR 0030](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0030-generated-project-validation.md))
 before rendered output is returned; `render_project` already calls it before
 `--engine-preview` receives a result.
-This repository now depends on a real, released `forge-template` range —
-`>=0.3.1,<0.4`, published to PyPI as the optional `engine` extra
+This repository depends on a real, released `forge-template` range —
+`>=0.4.1,<0.5`. [ADR 0026](docs/adr/0026-adopt-the-0-4-engine-compatibility-line.md)
+moved it from the first assigned `>=0.3.1,<0.4`, and
+[ADR 0031](docs/adr/0031-adopt-the-reviewed-forge-template-0-4-1-release.md)
+adopted the reviewed `0.4.1` release as its lower bound. It is published to
+PyPI with
+`uv>=0.12,<0.13` as the optional `engine` extra
 (`pip install 'create-forge[engine]'`; [#9](https://github.com/Sandsy09/create-forge/issues/9),
 [ADR 0018](docs/adr/0018-pypi-distribution-and-the-first-engine-range.md)) —
 rather than a development-only pin. That range is reachable only behind
@@ -190,12 +231,76 @@ issue.
 
 ## Using this at work
 
-In v0.1.x, organisations needing custom executable templates can fork this
-repository, point the bundled registry at their own templates, and maintain it
-internally. The accepted target makes a downstream client of the
-`forge-template` public engine the preferred route for organisation defaults
-and constraints. Forks remain appropriate for genuinely custom executable
-template content; see the [integration contract](docs/integration-contract.md).
+The preferred route for organisation defaults, required selections, and
+forbidden selections is a downstream client of the public `forge-template`
+engine, resolving the canonical
+[organisation-policy protocol](https://github.com/Sandsy09/forge-template/blob/main/docs/organisation-policy.md)
+before constructing a ProjectSpec — see the canonical
+[downstream policy-consumption contract](docs/organisation-policy-consumption.md)
+and [ADR 0022](docs/adr/0022-downstream-organisation-policy-hook.md).
+[`examples/downstream_cli.py`](examples/downstream_cli.py) is a runnable,
+second, independent client demonstrating exactly this — no dependency on
+`create-forge` at all — see the canonical
+[downstream client reference](docs/downstream-client-reference.md) and
+[ADR 0023](docs/adr/0023-downstream-client-reference.md).
+[ADR 0024](docs/adr/0024-reference-client-not-framework-dependency.md)
+completes the Stage 09 boundary: `create-forge` is one reference client, not a
+framework dependency for that client, the engine, or generated projects.
+
+Forking this repository remains appropriate only for genuinely custom
+executable template content that has no equivalent in the reviewed public
+engine — point the bundled registry at your own templates and maintain the
+fork internally, as v0.1.x always supported. See the
+[integration contract](docs/integration-contract.md) for the full boundary.
+
+The [accepted Data Science shape](https://github.com/Sandsy09/forge-template/blob/main/docs/data-science-archetype.md)
+is an independent, package-backed, notebook-oriented third archetype. The
+[initial capability contracts](https://github.com/Sandsy09/forge-template/blob/main/docs/data-science-capabilities.md)
+define its required reusable Jupyter tooling and independently optional
+Scientific Python stack. FT-11.02 implements Jupyter under [ADR
+0050](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0050-production-jupyter-capability.md),
+and FT-11.03 implements Scientific Python under [ADR
+0051](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0051-production-scientific-python-capability.md).
+Stage 11 then validated their production composition, and Stage 12 added and
+validated the `data-science` archetype. The complete five-component catalogue
+is published as
+[`forge-template 0.4.0`](https://github.com/Sandsy09/forge-template/releases/tag/v0.4.0)
+on [PyPI](https://pypi.org/project/forge-template/0.4.0/); its
+[published acceptance evidence](https://github.com/Sandsy09/forge-template/blob/main/docs/data-science-validation.md#published-040-release-verification)
+was the immutable provider hand-off to Stage 13.
+[CF-13.01](https://github.com/Sandsy09/create-forge/issues/106)
+([ADR 0026](docs/adr/0026-adopt-the-0-4-engine-compatibility-line.md)) adopted
+`forge-template>=0.4,<0.5`, so the engine-preview path now discovers all five
+components, and CF-13.02
+([ADR 0027](docs/adr/0027-generic-component-selection-conventions.md)) fixed
+how they are selected in the canonical
+[component selection contract](docs/component-selection.md). CF-13.03
+([ADR 0028](docs/adr/0028-discovery-driven-component-selection.md)) implemented
+capability and platform selection behind `--engine-preview`, and CF-13.04
+([ADR 0029](docs/adr/0029-per-component-option-collection.md)) per-component
+option collection and `--component-option`. CF-13.05
+([ADR 0030](docs/adr/0030-data-science-preview-pipeline-validation.md))
+validated the Data Science composition through the shared pipeline against the
+released engine, closing **Stage 13**; Stage 14 then takes the released client
+and engine pair through installed-console validation and rollout. CF-14.01
+([ADR 0031](docs/adr/0031-adopt-the-reviewed-forge-template-0-4-1-release.md))
+adopts the reviewed `forge-template 0.4.1` release as the new
+`>=0.4.1,<0.5` lower bound and prepares create-forge `0.3.0`. CF-14.02
+([ADR 0032](docs/adr/0032-validate-installed-data-science-generation.md))
+validates both Data Science compositions through the installed candidate
+wheel, and CF-14.03
+([ADR 0033](docs/adr/0033-complete-rollout-regression-validation.md)) reuses it
+for the Library / CLI Application engine paths, the engine-less default Copier
+path, a real out-of-range engine, and the full failure matrix; CF-14.04 owns
+publication. See the canonical
+[installed Data Science validation](docs/installed-data-science-validation.md)
+and
+[rollout regression and failure validation](docs/rollout-regression-validation.md)
+records. The
+[Data Science roadmap](docs/roadmap-v2/README.md) runs Stages 10–14.
+All 24 child issues are filed and attached across both repositories; GitHub
+issue bodies and native relationships are authoritative. The default Copier
+path remains unchanged.
 
 ## Contributing
 

create_forge-0.3.0/README.md

@@ -0,0 +1,280 @@
+# create-forge
+
+[![CI](https://github.com/Sandsy09/create-forge/actions/workflows/ci.yml/badge.svg)](https://github.com/Sandsy09/create-forge/actions/workflows/ci.yml)
+
+Scaffold modern Python projects from maintained templates — and pull template
+improvements back into projects you generated months ago.
+
+```bash
+uvx create-forge new
+```
+
+No install step. Requires [uv](https://docs.astral.sh/uv/) and git.
+
+## Why
+
+Most project generators are fire-and-forget: you scaffold once, and from that
+moment your project drifts away from the template. Six months later the template
+has better lint rules, a security fix in CI, and a newer toolchain — and no path
+to get any of it into projects already in the wild.
+
+create-forge is built on [Copier](https://copier.readthedocs.io/), which does a
+three-way merge between the template version your project was generated from and
+the latest one. Local edits survive; template changes arrive.
+
+```bash
+uvx create-forge update
+```
+
+## What you get
+
+Every generated project ships with:
+
+- **[uv](https://docs.astral.sh/uv/)** for packaging and dependency management
+- **[Ruff](https://docs.astral.sh/ruff/)** for linting and formatting
+- **mypy** or **pyright** (or both) for type checking
+- **pytest** with coverage
+- **pre-commit** hooks, including Conventional Commits enforcement
+- **GitHub Actions** CI, with a test matrix across your supported Python versions
+- **Renovate** or **Dependabot** for dependency updates
+- `README`, `CONTRIBUTING`, `SECURITY`, `CHANGELOG`, issue and PR templates
+- Optionally: a MkDocs documentation site and ADR scaffolding
+
+Choices you make at scaffold time — build backend, versioning strategy, license,
+type checker — are remembered, so updates respect them.
+
+## Usage
+
+```bash
+# Interactive
+uvx create-forge new
+
+# Named up front
+uvx create-forge new "Credit Risk Utils"
+
+# Non-interactive, for scripts and CI
+uvx create-forge new "My Lib" --yes \
+  --data build_backend=hatchling \
+  --data versioning=vcs \
+  --data type_checking=both
+
+# Validate an update without changing project files
+uvx create-forge update --dry-run
+```
+
+| Command | What it does |
+| --- | --- |
+| `new` | Create a project |
+| `list` | Show available templates |
+| `update` | Pull template changes into an existing project |
+| `doctor` | Check your environment can scaffold and update |
+| `config` | Inspect or initialise your saved configuration |
+
+Useful flags on `new`: `--template/-t`, `--path/-p`, `--data/-d`, `--yes/-y`,
+`--ref`, `--dry-run`.
+
+Useful flags on `update`: `--ref`, `--dry-run`. An update dry run validates the
+requested template update but does not apply it or produce a file-by-file diff.
+
+## Configuration
+
+Optional. Saves retyping the same answers:
+
+```toml
+# ~/.config/create-forge/config.toml
+author_name = "Your Name"
+author_email = "you@example.com"
+github_org = "your-org"
+default_template = "library"
+```
+
+`create-forge config init` writes a commented starter file at that path
+without overwriting one that already exists. `create-forge config show`
+prints the resolved values and where each came from.
+
+`github_org` pre-fills its prompt — you're still asked, just with the answer
+already typed in. `author_name` and `author_email` aren't prompted for at all,
+so a configured value is applied directly. `default_template` picks which
+template `new` offers first, interactively or under `--yes`.
+
+Every key can be overridden with an environment variable —
+`FORGE_GITHUB_ORG` and so on — or a command line flag. Precedence is
+config < environment < `--data` < an interactive answer.
+
+## Templates
+
+Run `create-forge list` for what your installed version offers. The registry is
+bundled with each release, so new templates arrive when you update the tool.
+
+To use your own template:
+
+```bash
+uvx create-forge new --template-url https://github.com/you/your-template
+```
+
+This describes the released v0.1.x architecture. Forge has accepted a future
+[public-engine integration contract](docs/integration-contract.md) in which a
+versioned `forge-template` package owns discovery and rendering. Its strict
+[ProjectSpec protocol v1](https://github.com/Sandsy09/forge-template/blob/main/docs/project-spec.md)
+and [component manifest protocol v1](https://github.com/Sandsy09/forge-template/blob/main/docs/component-manifests.md)
+are now implemented behind the canonical
+[stable template-engine API](https://github.com/Sandsy09/forge-template/blob/main/docs/template-engine-api.md)
+([ADR 0029](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0029-stable-template-engine-api.md)).
+The canonical
+[organisation-policy protocol v1](https://github.com/Sandsy09/forge-template/blob/main/docs/organisation-policy.md)
+defines how downstream clients resolve component-selection defaults and
+constraints before constructing that effective ProjectSpec. CF-09.01
+([ADR 0022](docs/adr/0022-downstream-organisation-policy-hook.md)) delivered
+the client-side consumption hook — this repository still resolves no policy
+itself; see the canonical
+[downstream policy-consumption contract](docs/organisation-policy-consumption.md).
+The canonical
+[safe extension contract](https://github.com/Sandsy09/forge-template/blob/main/docs/extension-points.md),
+[organisation-policy fixture](https://github.com/Sandsy09/forge-template/blob/main/docs/organisation-policy-fixtures.md),
+[compatibility policy](https://github.com/Sandsy09/forge-template/blob/main/docs/compatibility-policy.md),
+and [no-copy proof](https://github.com/Sandsy09/forge-template/blob/main/docs/no-copy-inheritance.md)
+complete forge-template's Stage 09 boundary. They deny arbitrary file
+replacement and prove that a client can retain policy/orchestration concerns
+without copying engine content or importing private engine modules. The
+decisions are recorded by forge-template
+[ADRs 0039](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0039-deny-policy-file-overrides.md),
+[0040](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0040-organisation-policy-reference-fixture.md),
+[0041](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0041-forge-blueprint-compatibility-policy.md),
+and [0042](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0042-validate-no-copy-downstream-inheritance.md).
+The accepted
+[Library archetype contract](https://github.com/Sandsy09/forge-template/blob/main/docs/library-archetype.md)
+defines the first production component, implemented on `forge-template/main`
+and released at `0.3.0`. The accepted
+[CLI Application archetype contract](https://github.com/Sandsy09/forge-template/blob/main/docs/cli-application-archetype.md)
+selects the optionless engine-owned `cli` archetype and derives its console
+command from `ProjectSpec.project.repository_name`;
+[FT-08.04](https://github.com/Sandsy09/forge-template/issues/4) implemented
+it in the same `0.3.0` release, and
+[CF-08.02](https://github.com/Sandsy09/create-forge/issues/10) exposes both
+archetypes behind the hidden `new --engine-preview` flag's `--archetype`
+option. Neither change alters this CLI's default `new` answers, registry, or
+released dependency surface.
+The Stage 08
+[composition architecture review](https://github.com/Sandsy09/forge-template/blob/main/docs/composition-architecture-review.md)
+is released in `forge-template 0.3.2`. On the engine-preview path,
+`create-forge 0.2.1` now finalises the validated in-memory render with
+`uv lock --directory <staging-directory>` before the atomic rename. The
+result contains `uv.lock` and uses `uv run --locked poe check`, while the
+default Copier path remains unchanged; see
+[ADR 0021](docs/adr/0021-client-finalises-engine-lockfiles.md).
+The engine now also defines in-memory
+[generated-project validation](https://github.com/Sandsy09/forge-template/blob/main/docs/generated-project-validation.md)
+([ADR 0030](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0030-generated-project-validation.md))
+before rendered output is returned; `render_project` already calls it before
+`--engine-preview` receives a result.
+This repository depends on a real, released `forge-template` range —
+`>=0.4.1,<0.5`. [ADR 0026](docs/adr/0026-adopt-the-0-4-engine-compatibility-line.md)
+moved it from the first assigned `>=0.3.1,<0.4`, and
+[ADR 0031](docs/adr/0031-adopt-the-reviewed-forge-template-0-4-1-release.md)
+adopted the reviewed `0.4.1` release as its lower bound. It is published to
+PyPI with
+`uv>=0.12,<0.13` as the optional `engine` extra
+(`pip install 'create-forge[engine]'`; [#9](https://github.com/Sandsy09/create-forge/issues/9),
+[ADR 0018](docs/adr/0018-pypi-distribution-and-the-first-engine-range.md)) —
+rather than a development-only pin. That range is reachable only behind
+`--engine-preview`; the current registry and `--template-url` behaviour
+remain unchanged until the complete, tested cutover is released — at which
+point `--engine-source`/`--engine-ref` (see the
+[engine resolution contract](docs/engine-resolution.md)) take over this role,
+not `--template-url`.
+
+## Security
+
+**create-forge executes code from the template it clones.** Copier templates can
+declare post-generation tasks, and this tool runs them — that is how a generated
+project arrives already git-initialised with hooks installed.
+
+The template addresses are compiled into each release rather than fetched at
+runtime or read from user configuration, so the only code trusted by default is
+code published alongside the tool. `--template-url` bypasses that, and prompts
+for confirmation before doing so. Point it only at repositories you trust.
+
+Report vulnerabilities per [SECURITY.md](SECURITY.md) rather than in a public
+issue.
+
+## Using this at work
+
+The preferred route for organisation defaults, required selections, and
+forbidden selections is a downstream client of the public `forge-template`
+engine, resolving the canonical
+[organisation-policy protocol](https://github.com/Sandsy09/forge-template/blob/main/docs/organisation-policy.md)
+before constructing a ProjectSpec — see the canonical
+[downstream policy-consumption contract](docs/organisation-policy-consumption.md)
+and [ADR 0022](docs/adr/0022-downstream-organisation-policy-hook.md).
+[`examples/downstream_cli.py`](examples/downstream_cli.py) is a runnable,
+second, independent client demonstrating exactly this — no dependency on
+`create-forge` at all — see the canonical
+[downstream client reference](docs/downstream-client-reference.md) and
+[ADR 0023](docs/adr/0023-downstream-client-reference.md).
+[ADR 0024](docs/adr/0024-reference-client-not-framework-dependency.md)
+completes the Stage 09 boundary: `create-forge` is one reference client, not a
+framework dependency for that client, the engine, or generated projects.
+
+Forking this repository remains appropriate only for genuinely custom
+executable template content that has no equivalent in the reviewed public
+engine — point the bundled registry at your own templates and maintain the
+fork internally, as v0.1.x always supported. See the
+[integration contract](docs/integration-contract.md) for the full boundary.
+
+The [accepted Data Science shape](https://github.com/Sandsy09/forge-template/blob/main/docs/data-science-archetype.md)
+is an independent, package-backed, notebook-oriented third archetype. The
+[initial capability contracts](https://github.com/Sandsy09/forge-template/blob/main/docs/data-science-capabilities.md)
+define its required reusable Jupyter tooling and independently optional
+Scientific Python stack. FT-11.02 implements Jupyter under [ADR
+0050](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0050-production-jupyter-capability.md),
+and FT-11.03 implements Scientific Python under [ADR
+0051](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0051-production-scientific-python-capability.md).
+Stage 11 then validated their production composition, and Stage 12 added and
+validated the `data-science` archetype. The complete five-component catalogue
+is published as
+[`forge-template 0.4.0`](https://github.com/Sandsy09/forge-template/releases/tag/v0.4.0)
+on [PyPI](https://pypi.org/project/forge-template/0.4.0/); its
+[published acceptance evidence](https://github.com/Sandsy09/forge-template/blob/main/docs/data-science-validation.md#published-040-release-verification)
+was the immutable provider hand-off to Stage 13.
+[CF-13.01](https://github.com/Sandsy09/create-forge/issues/106)
+([ADR 0026](docs/adr/0026-adopt-the-0-4-engine-compatibility-line.md)) adopted
+`forge-template>=0.4,<0.5`, so the engine-preview path now discovers all five
+components, and CF-13.02
+([ADR 0027](docs/adr/0027-generic-component-selection-conventions.md)) fixed
+how they are selected in the canonical
+[component selection contract](docs/component-selection.md). CF-13.03
+([ADR 0028](docs/adr/0028-discovery-driven-component-selection.md)) implemented
+capability and platform selection behind `--engine-preview`, and CF-13.04
+([ADR 0029](docs/adr/0029-per-component-option-collection.md)) per-component
+option collection and `--component-option`. CF-13.05
+([ADR 0030](docs/adr/0030-data-science-preview-pipeline-validation.md))
+validated the Data Science composition through the shared pipeline against the
+released engine, closing **Stage 13**; Stage 14 then takes the released client
+and engine pair through installed-console validation and rollout. CF-14.01
+([ADR 0031](docs/adr/0031-adopt-the-reviewed-forge-template-0-4-1-release.md))
+adopts the reviewed `forge-template 0.4.1` release as the new
+`>=0.4.1,<0.5` lower bound and prepares create-forge `0.3.0`. CF-14.02
+([ADR 0032](docs/adr/0032-validate-installed-data-science-generation.md))
+validates both Data Science compositions through the installed candidate
+wheel, and CF-14.03
+([ADR 0033](docs/adr/0033-complete-rollout-regression-validation.md)) reuses it
+for the Library / CLI Application engine paths, the engine-less default Copier
+path, a real out-of-range engine, and the full failure matrix; CF-14.04 owns
+publication. See the canonical
+[installed Data Science validation](docs/installed-data-science-validation.md)
+and
+[rollout regression and failure validation](docs/rollout-regression-validation.md)
+records. The
+[Data Science roadmap](docs/roadmap-v2/README.md) runs Stages 10–14.
+All 24 child issues are filed and attached across both repositories; GitHub
+issue bodies and native relationships are authoritative. The default Copier
+path remains unchanged.
+
+## Contributing
+
+See [CONTRIBUTING.md](CONTRIBUTING.md). Issues and pull requests welcome.
+Significant design decisions are recorded in [docs/adr/](docs/adr/).
+
+## License
+
+MIT — see [LICENSE](LICENSE).

{create_forge-0.2.0 → create_forge-0.3.0}/docs/adr/README.md

@@ -21,6 +21,21 @@ format](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
 - [0016 — Test the reference client end to end against the released template](0016-end-to-end-reference-client-tests.md)
 - [0017 — Expose the CLI Application archetype through discovery-driven selection](0017-cli-application-archetype-exposure.md)
 - [0018 — Publish to PyPI and assign the first bounded engine range](0018-pypi-distribution-and-the-first-engine-range.md)
+- [0019 — CLI archetype-parity review](0019-cli-archetype-parity-review.md)
+- [0020 — Test the public engine path end to end](0020-engine-path-end-to-end-tests.md)
+- [0021 — Finalise engine-generated lockfiles in the client](0021-client-finalises-engine-lockfiles.md)
+- [0022 — Downstream organisation-policy consumption hook](0022-downstream-organisation-policy-hook.md)
+- [0023 — Downstream client reference](0023-downstream-client-reference.md)
+- [0024 — Keep create-forge a reference client, not a framework dependency](0024-reference-client-not-framework-dependency.md)
+- [0025 — Prompt the engine path from discovery, not the Copier registry](0025-engine-native-prompt-flow.md)
+- [0026 — Adopt the forge-template 0.4 compatibility line](0026-adopt-the-0-4-engine-compatibility-line.md)
+- [0027 — Select components from discovery, with owner-qualified options](0027-generic-component-selection-conventions.md)
+- [0028 — Select capabilities and platforms from one discovered catalogue](0028-discovery-driven-component-selection.md)
+- [0029 — Collect and serialise options for every selected component](0029-per-component-option-collection.md)
+- [0030 — Validate the Data Science preview pipeline against the released engine](0030-data-science-preview-pipeline-validation.md)
+- [0031 — Adopt the reviewed forge-template 0.4.1 release](0031-adopt-the-reviewed-forge-template-0-4-1-release.md)
+- [0032 — Validate Data Science through the installed create-forge candidate](0032-validate-installed-data-science-generation.md)
+- [0033 — Complete the rollout regression and failure matrix at the installed boundary](0033-complete-rollout-regression-validation.md)
 
 Add a new record by copying the most recent one and incrementing the number.
 Records are immutable: supersede them rather than editing.

{create_forge-0.2.0 → create_forge-0.3.0}/docs/roadmap-v1/README.md

@@ -1,5 +1,9 @@
 # Forge Foundation Roadmap Pack — Two-Repository Edition
 
+> **Completed historical roadmap.** Stages 00–09 are closed. Paths remain
+> stable as decision and issue evidence. New Data Science work continues in
+> the [Stage 10–14 roadmap](../roadmap-v2/README.md).
+
 This revision models Forge as two independent repositories that work together through an explicit contract:
 
 - **`forge-template`** owns generated content, component metadata and the template/composition engine.
@@ -13,13 +17,17 @@ define the mandatory generated-project outcomes, while the
 defines which concerns may belong in that baseline. The
 [Library archetype contract](https://github.com/Sandsy09/forge-template/blob/main/docs/library-archetype.md)
 defines the first production archetype, implemented on
-`forge-template/main` and released at `0.3.0`. The
+`forge-template/main`, released at `0.3.0`, and included in the completed
+two-archetype [composition review](https://github.com/Sandsy09/forge-template/blob/main/docs/composition-architecture-review.md)
+released at `0.3.2`. The
 [CLI Application archetype contract](https://github.com/Sandsy09/forge-template/blob/main/docs/cli-application-archetype.md)
 selects the engine-owned, optionless `cli` archetype and derives its command
 from `ProjectSpec.project.repository_name`; FT-08.04 implemented it, and
 CF-08.02 exposes both archetypes behind `create-forge`'s hidden
 `--engine-preview` flag. Neither contract changes this repository's default
-`new` path or unassigned released engine range. The
+`new` path. `create-forge 0.2.1` keeps the released engine range unchanged and
+adds client-owned lock finalisation under
+[ADR 0021](../adr/0021-client-finalises-engine-lockfiles.md). The
 [Python support policy](https://github.com/Sandsy09/forge-template/blob/main/docs/python-support.md)
 defines the generated-project CPython window, defaults, and release lifecycle.
 The [editor integration strategy](https://github.com/Sandsy09/forge-template/blob/main/docs/editor-integration.md)
@@ -47,8 +55,23 @@ workflows, which remain independently owned and unchanged.
 The canonical
 [ProjectSpec protocol v1](https://github.com/Sandsy09/forge-template/blob/main/docs/project-spec.md)
 defines the strict effective generation request owned by `forge-template`.
-`create-forge` retains construction and user-facing orchestration, which remain
-unimplemented until the supported engine cutover.
+`create-forge` retains construction and user-facing orchestration. The canonical
+[organisation-policy protocol v1](https://github.com/Sandsy09/forge-template/blob/main/docs/organisation-policy.md)
+defines how downstream clients resolve component-selection policy before
+constructing that effective request. CF-09.01
+([ADR 0022](https://github.com/Sandsy09/create-forge/blob/main/docs/adr/0022-downstream-organisation-policy-hook.md))
+delivered the client hook; `create-forge` still consumes no policy itself.
+Forge-template Epic 09 is complete through its canonical
+[extension contract](https://github.com/Sandsy09/forge-template/blob/main/docs/extension-points.md),
+[policy fixture](https://github.com/Sandsy09/forge-template/blob/main/docs/organisation-policy-fixtures.md),
+[compatibility policy](https://github.com/Sandsy09/forge-template/blob/main/docs/compatibility-policy.md),
+and [no-copy proof](https://github.com/Sandsy09/forge-template/blob/main/docs/no-copy-inheritance.md).
+Forge-template [ADRs 0039–0042](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/README.md)
+record those four decisions.
+Create-forge Epic #40 and #53–#55 are complete under
+[ADR 0024](../adr/0024-reference-client-not-framework-dependency.md), which
+validates the client-owned half without making `create-forge` a shared
+framework dependency.
 The canonical
 [component manifest protocol v1](https://github.com/Sandsy09/forge-template/blob/main/docs/component-manifests.md)
 defines engine-owned bundled component metadata and compatibility. The
@@ -60,12 +83,8 @@ The canonical
 [generated-project validation contract](https://github.com/Sandsy09/forge-template/blob/main/docs/generated-project-validation.md)
 and [ADR 0030](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0030-generated-project-validation.md)
 complete the `forge-template` side of Stage 07 by validating rendered output
-in memory. The shared stage remains open for `create-forge` CLI orchestration,
-filesystem safety, and end-to-end coverage.
-`forge-template/main` now contains the Library production catalogue, while
-this repository's exact development pin still sees the earlier empty
-catalogue. CLI Application implementation and coordinated CLI discovery remain
-later work.
+in memory. Stage 07 and Stage 08 are now complete across both repositories;
+the default Copier-to-engine cutover remains separate future work.
 This roadmap links to the canonical sources rather than maintaining second
 definitions.
 

{create_forge-0.2.0 → create_forge-0.3.0}/docs/roadmap-v1/roadmap/07-forge-cli-integration/README.md

@@ -60,9 +60,15 @@ the *public engine* against a *released* engine-and-assets unit -- because
 neither exists yet: `forge-template` has no `0.2.x` release and its
 production catalogue stays empty until
 [FT-08.02 / forge-template#41](https://github.com/Sandsy09/forge-template/issues/41).
-Those two criteria carry forward verbatim to **CF-08.04**, filed under
+Those two criteria carried forward verbatim to **CF-08.04**, filed under
 [CF-EPIC-08](https://github.com/Sandsy09/create-forge/issues/39) and blocked
-on the same two things. See the canonical
+on the same two things at the time. Both blockers have since resolved --
+[FT-08.02 / forge-template#41](https://github.com/Sandsy09/forge-template/issues/41)
+shipped the production catalogue, and
+[#9](https://github.com/Sandsy09/create-forge/issues/9) published a released
+engine range -- and CF-08.04 is complete
+([ADR 0020](https://github.com/Sandsy09/create-forge/blob/main/docs/adr/0020-engine-path-end-to-end-tests.md)).
+See the canonical
 [end-to-end tests contract](https://github.com/Sandsy09/create-forge/blob/main/docs/end-to-end-tests.md).
 The atomic cutover that replaces both the v0.1.x registry seam and
 `--engine-preview` stays gated on