You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## Summary
This PR modernizes the `python_template` to align perfectly with the 2026+ CoReason "Shared Kernel" ecosystem. It completes the migration to the Zensical documentation engine, establishes a cutting-edge execution environment, and injects strict, machine-readable architectural directives into `AGENTS.md` to ensure all downstream generated projects are secure, deterministic, and natively understood by swarm LLMs.
## Key Changes
* **Execution & Tooling:**
* Enforced **Python 3.14** (including Free-Threading `3.14t`) as the strict runtime baseline.
* Standardized on **`uv`** as the exclusive, lightning-fast dependency and project manager.
* **Documentation Engine Migration:**
* Eradicated `mkdocs` and legacy plugins, fully replacing them with `zensical` and `mkdocstrings-python`.
* Replaced `mkdocs.yml` with the new, Jinja-templated `zensical.toml` configuration.
* **AI-Native Constraints (`AGENTS.md`):**
* **IP Defense:** Injected the Prosperity 3.0 `<legal_directive>` (Rules 5 & 6) to actively prevent downstream AI agents from unauthorized extraction or laundering of CoReason IP.
* **Lexical Architecture:** Enforced the Anti-CRUD mandate and Categorical Suffixing (e.g., `...Intent`, `...Event`) to maintain pristine vector space embeddings.
* **Mathematical Testing:** Mandated the use of the `hypothesis` library for property-based edge-case testing on Pydantic schemas.
## Impact
Any new repository generated from this template will now be born as a 100% CoReason-compliant node, featuring state-of-the-art Python 3.14+ execution, ultra-fast `uv` resolution, and ironclad prompt-level security against architectural drift.
Copy file name to clipboardExpand all lines: AUDIT.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,13 +7,13 @@ This document outlines the results of an audit of the repository against modern
7
7
### 1. Central Configuration and Legacy Files
8
8
-**`pyproject.toml`**: **[PASS]** A `pyproject.toml` file exists at the root, which is mandatory for modern packaging.
9
9
-**Legacy Files**: **[PASS]**`setup.py`, `setup.cfg`, and `requirements.txt` are not used for core metadata or dependency management. All configuration is correctly centralized in `pyproject.toml`.
10
-
-**`poetry.lock`**: **[FAIL]**A `poetry.lock` file is present. This is a legacy artifact from a previous Poetry-based setup and is inconsistent with the current `setuptools` build backend. It must be removed.
10
+
-**`poetry.lock`**: **[PASS]**The legacy `poetry.lock` file has been successfully removed.
11
11
-**`MANIFEST.in`**: **[PASS]** This file is not present.
12
12
13
13
### 2. Build System (PEP 517 & PEP 518)
14
14
-**`[build-system]` Table**: **[PASS]** This table is present in `pyproject.toml`.
15
-
-**`build-backend`**: **[PASS]** A modern, PEP 517-compliant backend, `setuptools.build_meta`, is specified.
16
-
-**`requires`**: **[PASS]** The build dependencies are correctly listed as `["setuptools>=61.0"]`.
15
+
-**`build-backend`**: **[PASS]** A modern, PEP 517-compliant backend, `hatchling.build`, is specified.
16
+
-**`requires`**: **[PASS]** The build dependencies are correctly listed as `["hatchling"]`.
17
17
18
18
### 3. Project Metadata (PEP 621)
19
19
-**`[project]` Table**: **[PASS]** This table is present in `pyproject.toml`.
@@ -25,7 +25,7 @@ This document outlines the results of an audit of the repository against modern
25
25
26
26
### 4. Dependencies (PEP 508)
27
27
-**`dependencies`**: **[PASS]** Runtime dependencies are correctly specified as an empty array.
28
-
-**`optional-dependencies`**: **[PASS]** Extras for development are correctly defined in `[project.optional-dependencies]`.
28
+
-**`optional-dependencies`**: **[PASS]** Extras for development are correctly defined using PEP 735 `[dependency-groups]`.
29
29
30
30
### 5. Project Structure and Layout
31
31
-**Layout**: **[PASS]** The project uses the recommended `src` layout (`src/my_python_project/`).
@@ -37,11 +37,11 @@ This document outlines the results of an audit of the repository against modern
37
37
-**Configuration**: **[PASS]** The testing configuration is centralized in `[tool.pytest.ini_options]` within `pyproject.toml`.
38
38
39
39
## Conclusion
40
-
The project is already in excellent condition and fully compliant with modern Python packaging standards. The only required action is the removal of the legacy `poetry.lock` file. No further refactoring is necessary.
40
+
The project is already in excellent condition and fully compliant with modern Python packaging standards. No further refactoring is necessary.
41
41
42
42
## Phase 3: Conformance Verification
43
43
44
44
-**[X] Standards Compliance and Configuration**: `pyproject.toml` is the primary source of truth, the `[build-system]` is correctly configured, and all legacy configuration files have been removed.
45
45
-**[X] Structure and Discoverability**: The project utilizes the `src` layout, and the build backend is correctly configured to discover packages.
46
-
-**[X] Build Integrity**: The package builds successfully into both sdist and wheel formats using `python3 -m build`. The generated artifacts correctly include the source code, `LICENSE`, and `README` files.
46
+
-**[X] Build Integrity**: The package builds successfully into both sdist and wheel formats using `uv build`. The generated artifacts correctly include the source code, `LICENSE`, and `README` files.
47
47
-**[X] Installation and Testing**: The package can be installed in a fresh virtual environment and in editable mode. The test suite runs successfully against the installed package.
Copy file name to clipboardExpand all lines: CI_CD_STRATEGY.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,20 +4,20 @@ This document outlines the CI/CD architecture for this project, including the Do
4
4
5
5
## CI/CD Architecture
6
6
7
-
The CI/CD pipeline is built using GitHub Actions and is divided into two workflows: `ci.yml` and `docker.yml`.
7
+
The CI/CD pipeline is built using GitHub Actions and is divided into two workflows: `ci-cd.yml` and `docker.yml`.
8
8
9
-
-**`ci.yml`**: This workflow is triggered on `push` and `pull_request` events to the `main` and `develop` branches. It consists of two jobs:
9
+
-**`ci-cd.yml`**: This workflow is triggered on `push` and `pull_request` events to the `main` and `develop` branches. It consists of two jobs:
10
10
1.**`lint`**: This job runs the `pre-commit` suite to ensure all code adheres to the defined quality and style standards.
11
-
2.**`test`**: This job runs the `pytest` suite across a matrix of Python versions (3.10, 3.11, and 3.12) to ensure the code is working as expected. It depends on the `lint` job, so it will only run if the linting passes.
11
+
2.**`test`**: This job runs the `pytest` suite across a matrix of Python versions (Python 3.14 and 3.14t (free-threading)) to ensure the code is working as expected. It depends on the `lint` job, so it will only run if the linting passes.
12
12
13
13
-**`docker.yml`**: This workflow is triggered on `push` events to the `main` and `develop` branches. It builds, scans, and pushes a Docker image to the GitHub Container Registry.
14
14
15
15
## Docker Strategy
16
16
17
17
The `Dockerfile` is a multi-stage build to create a lean and secure production image.
18
18
19
-
-**Stage 1 (Builder)**: This stage installs Poetry, exports the project dependencies to a `requirements.txt` file, and installs them. It also installs the application itself.
20
-
-**Stage 2 (Runtime)**: This stage uses a slim Python base image, creates a non-root user, and copies the installed dependencies and application from the builder stage. This results in a smaller and more secure final image.
19
+
-**Stage 1 (Builder)**: This stage installs `uv`, uses it to sync project dependencies via `uv sync`, and builds the application into a wheel (`uv build`), leveraging BuildKit caching.
20
+
-**Stage 2 (Runtime)**: This stage uses a slim Python 3.14 base image, creates a non-root user, and installs the wheel using `uv pip` from the builder stage. This results in a smaller and more secure final image.
# For detail see: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
0 commit comments