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

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

@@ -1,6 +1,41 @@
 # 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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: create-forge
-Version: 0.2.1
+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,7 @@ 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
 
@@ -89,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 |
@@ -102,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:
@@ -146,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`
@@ -172,9 +199,13 @@ The engine now also defines in-memory
 ([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 with `uv>=0.12,<0.13` 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
@@ -200,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.2.1 → create_forge-0.3.0}/README.md

@@ -57,6 +57,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 |
@@ -70,6 +73,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:
@@ -114,6 +120,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`
@@ -140,9 +167,13 @@ The engine now also defines in-memory
 ([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 with `uv>=0.12,<0.13` 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
@@ -168,12 +199,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.2.1 → create_forge-0.3.0}/docs/adr/README.md

@@ -24,6 +24,18 @@ format](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
 - [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.1 → 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.
@@ -51,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

{create_forge-0.2.1 → create_forge-0.3.0}/docs/roadmap-v1/roadmap/08-reference-archetype-validation/README.md

@@ -44,7 +44,11 @@
   (`pipeline._resolved_component_options`) is now gated by a discovered
   descriptor rather than a hardcoded archetype id. The engine path's
   Library-shaped prompt set was recorded, not fixed, and tracked by
-  [create-forge#91](https://github.com/Sandsy09/create-forge/issues/91).
+  [create-forge#91](https://github.com/Sandsy09/create-forge/issues/91) —
+  since closed via
+  [ADR 0025](https://github.com/Sandsy09/create-forge/blob/main/docs/adr/0025-engine-native-prompt-flow.md):
+  `--engine-preview` now prompts directly from the selected archetype's own
+  discovered `ComponentDescriptor.options` and reads no registry data at all.
 - ~~**CF-08.04 — Extend end-to-end generation to the public engine**~~ —
   complete via
   [ADR 0020](https://github.com/Sandsy09/create-forge/blob/main/docs/adr/0020-engine-path-end-to-end-tests.md)

create_forge-0.3.0/docs/roadmap-v1/roadmap/09-blueprint-compatibility/README.md

@@ -0,0 +1,62 @@
+# Stage 09 — Blueprint Compatibility
+
+## Repository ownership
+
+### forge-template
+
+- [x] **FT-09.01 — Define organisation policy model** — completed by the
+  canonical [organisation-policy protocol v1](https://github.com/Sandsy09/forge-template/blob/main/docs/organisation-policy.md),
+  [ADR 0038](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0038-organisation-policy-selection-model.md),
+  and [forge-template PR #89](https://github.com/Sandsy09/forge-template/pull/89).
+- [x] **FT-09.02 — Define safe override and extension points** — completed by
+  the canonical [extension contract](https://github.com/Sandsy09/forge-template/blob/main/docs/extension-points.md),
+  [ADR 0039](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0039-deny-policy-file-overrides.md),
+  and [forge-template PR #90](https://github.com/Sandsy09/forge-template/pull/90).
+- [x] **FT-09.03 — Create generic downstream policy reference fixture** —
+  completed by the canonical [fixture guide](https://github.com/Sandsy09/forge-template/blob/main/docs/organisation-policy-fixtures.md),
+  [ADR 0040](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0040-organisation-policy-reference-fixture.md),
+  and [forge-template PR #91](https://github.com/Sandsy09/forge-template/pull/91).
+- [x] **FT-09.04 — Define Forge-Blueprint compatibility policy** — completed
+  by the canonical [compatibility policy](https://github.com/Sandsy09/forge-template/blob/main/docs/compatibility-policy.md),
+  [ADR 0041](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0041-forge-blueprint-compatibility-policy.md),
+  and [forge-template PR #92](https://github.com/Sandsy09/forge-template/pull/92).
+- [x] **FT-09.05 — Validate no-copy inheritance model** — completed by the
+  canonical [no-copy proof](https://github.com/Sandsy09/forge-template/blob/main/docs/no-copy-inheritance.md),
+  [ADR 0042](https://github.com/Sandsy09/forge-template/blob/main/docs/adr/0042-validate-no-copy-downstream-inheritance.md),
+  and [forge-template PR #93](https://github.com/Sandsy09/forge-template/pull/93).
+
+Forge-template [Epic #18](https://github.com/Sandsy09/forge-template/issues/18)
+and its milestone are complete. Its contracts keep policy selection-only,
+deny arbitrary file replacement, define compatibility, and prove public-
+facade reuse without copied Foundation/component source. The private fixture
+catalogue remains a forge-template test seam, not a client plugin mechanism.
+
+### create-forge
+
+- Epic: [CF-EPIC-09 / #40](https://github.com/Sandsy09/create-forge/issues/40)
+- [x] [**CF-09.01 — Define downstream policy-consumption hook**](https://github.com/Sandsy09/create-forge/issues/53)
+  — complete. `pipeline.build_generation_request` accepts a `selection`/
+  `provenance` pair built from `spec.SelectionRequest`/`SelectionProvenance`;
+  `create-forge` ships no resolver and reads no policy document by design.
+  See [ADR 0022](https://github.com/Sandsy09/create-forge/blob/main/docs/adr/0022-downstream-organisation-policy-hook.md)
+  and the canonical [downstream policy-consumption contract](https://github.com/Sandsy09/create-forge/blob/main/docs/organisation-policy-consumption.md).
+- [x] [**CF-09.02 — Create downstream CLI integration reference**](https://github.com/Sandsy09/create-forge/issues/54)
+  — complete. `examples/downstream_cli.py`: a second, independent
+  Blueprint-style CLI over the public `forge_template` facade, with its own
+  compatibility bounds and its own minimal organisation-policy resolver, and
+  no dependency on `create-forge` at all (an AST guard proves it). See
+  [ADR 0023](https://github.com/Sandsy09/create-forge/blob/main/docs/adr/0023-downstream-client-reference.md)
+  and the canonical [downstream client reference](https://github.com/Sandsy09/create-forge/blob/main/docs/downstream-client-reference.md).
+- [x] [**CF-09.03 — Validate create-forge is a reference client, not a framework dependency**](https://github.com/Sandsy09/create-forge/issues/55)
+  — complete. [ADR 0024](../../../adr/0024-reference-client-not-framework-dependency.md)
+  records the strict one-way dependency, the living
+  [integration contract](../../../integration-contract.md) maps every
+  acceptance criterion to executable evidence, and both production
+  archetypes are checked for Forge-free generated dependencies and locks.
+
+## Stage completion rule
+
+- [x] Repo-local issues are complete or explicitly deferred.
+- [x] Cross-repository blockers are resolved.
+- [x] Public contracts changed by this stage are documented/versioned.
+- [x] No implementation concern is duplicated across repositories.

create_forge-0.3.0/docs/roadmap-v2/README.md

@@ -0,0 +1,55 @@
+# Forge Data Science Roadmap — Two-Repository Edition
+
+This roadmap continues the completed
+[Forge Foundation roadmap](../roadmap-v1/README.md) through Stages 10–14.
+It plans the next production archetype without reopening the Foundation,
+composition, reference-client, or Blueprint decisions completed in Stages
+00–09.
+
+The target is a package-backed, notebook-oriented Data Science project with
+reusable optional capabilities. Exact scientific libraries, notebook front
+ends, data-versioning systems, model tooling, and deployment integrations are
+not selected here; Stage 10 owns those decisions.
+
+Delivery remains behind `create-forge new --engine-preview`. Retiring the
+default direct-Copier path is a separate future initiative.
+
+Stages 10–12 are complete. The package-bound 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/). Stage 13 is
+complete: CF-13.01 (ADR 0026) adopted the `forge-template>=0.4,<0.5`
+compatibility line, so `--engine-preview` discovery now returns all five
+descriptors, and CF-13.02 (ADR 0027) fixed the generic component-selection
+CLI conventions, which CF-13.03 (ADR 0028) implemented for capabilities and
+platforms and CF-13.04 (ADR 0029) for per-component options, and CF-13.05
+(ADR 0030) validated the Data Science composition through the shared pipeline
+against the released engine, closing CF-EPIC-13. Stage 14 takes the released
+client and engine pair through installed-console validation and rollout.
+Provider Stage 14 is complete and published the reviewed
+`forge-template 0.4.1` release. CF-14.01 (ADR 0031) adopts it as create-forge's
+`>=0.4.1,<0.5` lower bound and prepares create-forge `0.3.0`; CF-14.02
+(ADR 0032) completes installed-console Data Science validation, and CF-14.03
+(ADR 0033) completes the installed regression and failure matrix. CF-14.04
+publishes the client and closes the Stage 14 milestones.
+
+## Repository roles
+
+- **forge-template** owns the Data Science contract, capabilities, archetype,
+  composition review, generated content, and engine releases.
+- **create-forge** owns discovery-driven user input, ProjectSpec construction,
+  diagnostics, staging, lock finalisation, and end-to-end client validation.
+
+See the [architecture](ARCHITECTURE.md),
+[ownership model](REPOSITORY-OWNERSHIP.md), and
+[stage roadmap](ROADMAP.md) for the complete boundary.
+
+## Live GitHub work
+
+Six epics and 24 child issues are filed across the two repositories. GitHub
+issue bodies and native parent/dependency relationships are authoritative:
+
+- [forge-template epic index](https://github.com/Sandsy09/forge-template/blob/main/docs/roadmap-v2/github-issues/forge-template/ISSUE-INDEX.md)
+- [create-forge epic index](https://github.com/Sandsy09/create-forge/blob/main/docs/roadmap-v2/github-issues/create-forge/ISSUE-INDEX.md)
+- [cross-repository dependency matrix](github-issues/CROSS-REPO-DEPENDENCIES.md)
+- [GitHub setup and taxonomy](github-issues/GITHUB-SETUP.md)

create_forge-0.3.0/docs/roadmap-v2/roadmap/10-data-science-architecture-contract/README.md

@@ -0,0 +1,61 @@
+# Stage 10 — Data Science Architecture Contract
+
+## Epic
+
+[FT-EPIC-10 / forge-template#96](https://github.com/Sandsy09/forge-template/issues/96)
+defines the contract before any component is implemented.
+
+## Dependencies
+
+This epic has no open native blocker. The roadmap begins only after completed
+`create-forge#91` and the completed Foundation roadmap provide its accepted
+engine and client baseline.
+
+## Child sequence
+
+1. [FT-10.01 / #101](https://github.com/Sandsy09/forge-template/issues/101)
+   is complete: the canonical
+   [Data Science contract](https://github.com/Sandsy09/forge-template/blob/main/docs/data-science-archetype.md)
+   defines the fixed package-plus-notebooks shape and ownership.
+2. [FT-10.02 / #102](https://github.com/Sandsy09/forge-template/issues/102)
+   is complete: the canonical
+   [initial capability contracts](https://github.com/Sandsy09/forge-template/blob/main/docs/data-science-capabilities.md)
+   define optionless `jupyter` and `scientific-python` components and bounded
+   dependency lines.
+3. [FT-10.03 / #103](https://github.com/Sandsy09/forge-template/issues/103)
+   defines notebook, data, model, secret, and generated-artefact safeguards.
+4. [FT-10.04 / #104](https://github.com/Sandsy09/forge-template/issues/104)
+   fixes compatibility, acceptance, and `forge-template` 0.4.0 release
+   requirements.
+
+Each child is blocked by the preceding item. With FT-10.02 complete, FT-10.03
+is the next actionable decision.
+
+## Entry criteria
+
+- Forge Foundation Stages 00–09 are complete.
+- Library and CLI Application prove independent production archetypes.
+- create-forge #91 has completed engine-native option prompting.
+
+## Outcomes
+
+- Define the minimal package-plus-notebooks project shape.
+- Assign every concern to Foundation, archetype, capability, platform,
+  profile, organisation policy, or client orchestration.
+- Define dependency-selection criteria rather than selecting tools by trend.
+- Define data, model, secret, path, environment, and generated-artifact
+  safeguards.
+- Define Python, lock, packaging, notebook-validation, and maintenance
+  expectations.
+- Classify all protocol, public API, component, engine, and client
+  compatibility impacts.
+
+## Exit criteria
+
+The four accepted decisions make the shape, capability boundaries,
+safeguards, compatibility impact, and acceptance strategy implementation-ready.
+
+## Non-goals
+
+No production component, dependency, generated output, CLI behavior, tag, or
+release is introduced in this stage.