python-ddd-framework 0.3.1__py3-none-any.whl → 0.3.2__py3-none-any.whl

{python_ddd_framework-0.3.1.dist-info → python_ddd_framework-0.3.2.dist-info}/METADATA

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-ddd-framework
-Version: 0.3.1
+Version: 0.3.2
 Summary: Modular DDD application framework with project CLI and bundled templates
 License-Expression: LicenseRef-Proprietary
 License-File: LICENSE
@@ -83,9 +83,9 @@ Runtime integrations ship in the base package; the Host explicitly enables the m
 - [uv](https://docs.astral.sh/uv/getting-started/installation/) for tool installation, dependency management, and project commands.
 - Docker with Compose, running locally, for the generated application's PostgreSQL and Redis services.
 
-The supported versions and dependencies are defined in [pyproject.toml](pyproject.toml). The framework, CLI, and bundled templates share one package version.
+The supported versions and dependencies are defined in [pyproject.toml](https://github.com/componet-architecture/python-ddd-framework/blob/main/pyproject.toml). The framework, CLI, and bundled templates share one package version.
 
-> **Version 0.3:** This version introduces the `python-ddd-framework` name, unified runtime installation, and application documentation templates. Check [release status](docs/status.md#当前发布) before selecting a PyPI version. Use the local-wheel route below when evaluating a checkout that has not been published.
+> **Version 0.3:** This version introduces the `python-ddd-framework` name, unified runtime installation, and application documentation templates. Check [release status](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/status.md#当前发布) before selecting a PyPI version. Use the local-wheel route below when evaluating a checkout that has not been published.
 
 ### 1. Install the CLI and create a project
 
@@ -224,7 +224,7 @@ For a new use case, define its input and output in `application_contracts/`, put
 
 For a model change, edit `sqlalchemy/models/`, generate a revision, review it, then run `db upgrade` for that module. For another business module, repeat the `add module`, `db revision`, `db upgrade`, and `db seed` steps. Add application-specific dependencies with `uv add <package>`.
 
-See the [development guide](docs/development.md) for service registration, typed invocation, HTTP declarations, transactions, background handlers, and distributed locks.
+See the [development guide](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/development.md) for service registration, typed invocation, HTTP declarations, transactions, background handlers, and distributed locks.
 
 ### Configure the application
 
@@ -232,7 +232,7 @@ Edit `app.development.yaml` for local connections, identity settings, logging, a
 
 `PYTHON_DDD_FRAMEWORK_ENVIRONMENT` selects the Host environment; it is separate from business configuration. Typed Options validate configuration during application composition. Use `uv run pddd inspect` to investigate input values and where they came from.
 
-Generated credentials are for local development. Production configuration is supplied separately in `app.production.yaml`. See [configuration](docs/development.md#定义-module-与配置) and [background and logging configuration](docs/development.md#settings后台与日志).
+Generated credentials are for local development. Production configuration is supplied separately in `app.production.yaml`. See [configuration](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/development.md#定义-module-与配置) and [background and logging configuration](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/development.md#settings后台与日志).
 
 ### Run application tests
 
@@ -242,7 +242,7 @@ After completing local database setup:
 uv run pytest
 ```
 
-The generated application includes module tests and Host tests. Keep Docker available for tests that use real infrastructure. For custom application tests, the framework's `TestApplication` reuses the normal application builder and typed service invocation. Framework contributor checks are documented separately in [framework validation](docs/development.md#框架验证).
+The generated application includes module tests and Host tests. Keep Docker available for tests that use real infrastructure. For custom application tests, the framework's `TestApplication` reuses the normal application builder and typed service invocation. Framework contributor checks are documented separately in [framework validation](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/development.md#框架验证).
 
 ## Deployment
 
@@ -259,7 +259,7 @@ For container deployment:
 3. Run database upgrades for each required module in dependency order. Run initial seed operations explicitly with `--environment production`.
 4. Start the web service from the same image and check its health endpoints.
 
-The image uses `python -m host.main` without development reload. Runtime installations use the base framework package; `developer-kit` is only needed for generation. Follow the [Docker deployment guide](docs/development.md#docker-交付) for commands and operational boundaries.
+The image uses `python -m host.main` without development reload. Runtime installations use the base framework package; `developer-kit` is only needed for generation. Follow the [Docker deployment guide](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/development.md#docker-交付) for commands and operational boundaries.
 
 <a id="版本与升级"></a>
 
@@ -279,7 +279,7 @@ uv run pytest
 uv build --no-sources
 ```
 
-During `0.x`, compatible fixes use a patch release; changes requiring consumer adaptation use a minor release with migration instructions. Publishing changed package contents requires a new version. Release evidence, including the limits of previously tested upgrade paths, is recorded in [status](docs/status.md).
+During `0.x`, compatible fixes use a patch release; changes requiring consumer adaptation use a minor release with migration instructions. Publishing changed package contents requires a new version. Release evidence, including the limits of previously tested upgrade paths, is recorded in [status](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/status.md).
 
 ### Migration notes
 
@@ -288,18 +288,18 @@ These notes remain the authoritative consumer migration instructions. Historical
 <a id="框架更名迁移未发布"></a>
 
 <details>
-<summary>0.3.1 — framework name, unified installation, and application guidance</summary>
+<summary>0.3.x — framework name, unified installation, and application guidance</summary>
 
-The distribution is `python-ddd-framework`, the import package is `python_ddd_framework`, and the CLI is `pddd`. Neither `python-platform` nor the unreleased intermediate name `python-modular-framework` retains a package, import, or command alias. The intermediate name belongs to a different PyPI project. Version `0.3.1` carries this breaking migration; `0.3.0` did not pass the release gate and was not published. Publication evidence is tracked in [release status](docs/status.md#当前发布).
+The distribution is `python-ddd-framework`, the import package is `python_ddd_framework`, and the CLI is `pddd`. Neither `python-platform` nor the unreleased intermediate name `python-modular-framework` retains a package, import, or command alias. The intermediate name belongs to a different PyPI project. Version `0.3.1` carries this breaking migration; `0.3.0` did not pass the release gate and was not published. Publication evidence is tracked in [release status](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/status.md#当前发布).
 
 - Replace dependency names, Python and dynamic imports, and entry point groups. Use `python_ddd_framework.hosts` and `python_ddd_framework.modules`. Replace `pp`/`pmf` commands, framework wheel source keys, and deployment commands, then relock and rebuild without regenerating business code.
-- Use `python-ddd-framework==0.3.1` for runtime dependencies and `python-ddd-framework[developer-kit]==0.3.1` for development. Remove former capability extras; the base package includes runtime integrations while the Host still selects and enables providers.
+- Use `python-ddd-framework==0.3.2` for runtime dependencies and `python-ddd-framework[developer-kit]==0.3.2` for development. Remove former capability extras; the base package includes runtime integrations while the Host still selects and enables providers.
 - New projects receive English setup, agent guidance, architecture, and development documents; newly generated modules receive a README. Existing applications are not regenerated or overwritten. Adopt the relevant guidance manually and preserve project-specific business rules and instructions.
 - Replace `PYTHON_PLATFORM_ENVIRONMENT` or `PYTHON_MODULAR_FRAMEWORK_ENVIRONMENT` with `PYTHON_DDD_FRAMEWORK_ENVIRONMENT`. New templates use `PDDD_` for business configuration; existing applications may retain their own business prefixes.
 - Stop old Hosts and workers before switching. The local lock directory is now `.python-ddd-framework`; old processes may still hold locks under the former directory.
 - Storage and protocol identifiers now use capability names. The default queue schema is `background_jobs`, the default Redis prefix is `app`, and generated applications use their project name as the Redis prefix. Table names, revisions, and branch labels follow their owning capability. WebSocket framework errors use `framework.problem.v1`.
 - There is no compatibility path for the old database, cache keys, or protocol identifiers. Recreate disposable development databases; explicitly migrate any data you need to retain. Installation identity remains configurable through `redis.key_prefix`, PgQueuer Options, and SQLAlchemy migration Options.
-- Give installations sharing a database separate Alembic version table names or schemas. A version table cannot reside in the queue's exclusive schema. PgQueuer notification channels derive from the schema and object prefix and do not reuse the old channel. Changing these identities for an existing installation requires explicit migration of data and migration records. See [configuration examples](docs/development.md#settings后台与日志).
+- Give installations sharing a database separate Alembic version table names or schemas. A version table cannot reside in the queue's exclusive schema. PgQueuer notification channels derive from the schema and object prefix and do not reuse the old channel. Changing these identities for an existing installation requires explicit migration of data and migration records. See [configuration examples](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/development.md#settings后台与日志).
 
 </details>
 
@@ -308,7 +308,7 @@ The distribution is `python-ddd-framework`, the import package is `python_ddd_fr
 <details>
 <summary>0.2.1 — application, HTTP, background, and persistence contracts</summary>
 
-The `0.2` line introduced changes requiring application updates. Version `0.2.0` did not pass the full CI gate and was not released; the corrected release used the former `python-platform` name at `0.2.1`. See the [historical release record](docs/status.md#当前发布). For that release, both runtime and developer-kit dependencies were pinned to `==0.2.1`. Consumption under the new name additionally requires the rename steps above.
+The `0.2` line introduced changes requiring application updates. Version `0.2.0` did not pass the full CI gate and was not released; the corrected release used the former `python-platform` name at `0.2.1`. See the [historical release record](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/status.md#当前发布). For that release, both runtime and developer-kit dependencies were pinned to `==0.2.1`. Consumption under the new name additionally requires the rename steps above.
 
 - **Repositories and service scopes:** Repository interfaces inherit `RepositoryContract, Protocol`; implementations belong in the persistence layer's `repositories/` package and are scanned by their module. Remove manual scope and interface mappings. Repositories use cached REQUEST scope, application-service implementations use ACTION, and `HostedService` uses cached APP scope. Conflicting lifecycle declarations and non-cached providers are rejected.
 - **Jobs and workers:** Move job declarations to class attributes and discover them through `Module.scan_packages`; enqueue with `enqueue(JobType, payload)`. Register worker classes in `Module.background_workers`, with interval and enabled state on the class. Remove explicit class Definition registration and `jobs.enabled` configuration. Function registrations and durable name/version/payload identities remain unchanged. Approval payloads require `order_id`; drain or explicitly migrate old statistics jobs instead of passing them to the approval handler.
@@ -322,10 +322,10 @@ The `0.2` line introduced changes requiring application updates. Version `0.2.0`
 <details>
 <summary>0.1.1 — public package consumption</summary>
 
-- `0.1.1` was the first public-installation target under the former name. `0.1.0` did not complete public release; the patch retriggered publishing without changing API, dependency, or database contracts. See [release evidence](docs/status.md#当前发布).
+- `0.1.1` was the first public-installation target under the former name. `0.1.0` did not complete public release; the patch retriggered publishing without changing API, dependency, or database contracts. See [release evidence](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/status.md#当前发布).
 - Project generation switched to exact PyPI dependencies while retaining same-version local-wheel validation. `--framework-source` and implicit Git-source inference were removed. Applications moving from private prereleases pinned runtime and developer-kit dependencies to `==0.1.1`, removed only the framework source override, then relocked and validated.
 - Dockerfiles may remove Git/SSH tooling and credential mounts used solely to fetch the framework; assess other Git dependencies separately. This consumption change introduced no framework schema migration.
-- New projects start with a Host skeleton and add business code through `add module`. Existing applications keep their source layout. Check their Host/module entry points and database ownership against the [development guide](docs/development.md#数据库聚合与迁移).
+- New projects start with a Host skeleton and add business code through `add module`. Existing applications keep their source layout. Check their Host/module entry points and database ownership against the [development guide](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/development.md#数据库聚合与迁移).
 
 </details>
 
@@ -349,31 +349,31 @@ Apply only the migrations relevant to your application. Completed migrations do
 | `ReferenceOrderView` or public `fail_after_add` | Use `ReferenceOrderDto` and remove the fault-injection parameter. The reference application's `reference_orders_0002` migration adds `version` to existing data; updates compete on the expected version. No old type alias remains. |
 | Interpreters or backports outside `requires-python` | Select a supported interpreter from package metadata, relock, and run application validation. |
 
-Do not remove durable job payload versions merely because their Python APIs were removed. First drain the queue or explicitly migrate its data. See [transaction and persistence boundaries](docs/architecture.md#uow持久化与本地事件).
+Do not remove durable job payload versions merely because their Python APIs were removed. First drain the queue or explicitly migrate its data. See [transaction and persistence boundaries](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/architecture.md#uow持久化与本地事件).
 
 </details>
 
 <details>
 <summary>For maintainers: publishing a changed version</summary>
 
-Routine code and documentation commits may retain the current version. Pushes to `main` still run CI but skip publication unless the version increased across the push; initial creation of `main` publishes its current version. Manual workflow runs validate only. A failed run may be retried, but a later same-version push does not resume publication: changed contents require another version bump. Follow [release operations](docs/development.md#发布操作) for publisher setup and retry boundaries. A future version is not evidence of a completed upgrade test.
+Routine code and documentation commits may retain the current version. Pushes to `main` still run CI but skip publication unless the version increased across the push; initial creation of `main` publishes its current version. Manual workflow runs validate only. A failed run may be retried, but a later same-version push does not resume publication: changed contents require another version bump. Follow [release operations](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/development.md#发布操作) for publisher setup and retry boundaries. A future version is not evidence of a completed upgrade test.
 
 </details>
 
 ## Documentation
 
-The guides below are currently maintained in Chinese; this README provides the English product and onboarding entry point.
+The engineering guides below are maintained in Chinese in the private GitHub repository and require repository access. This README and the documents bundled with generated applications provide the English product and development guides.
 
 | If you need to… | Read |
 | --- | --- |
-| Implement services, configure modules, or operate the database | [Development and operations](docs/development.md) |
-| Understand ownership, lifecycle, transaction, and failure guarantees | [Architecture and contracts](docs/architecture.md) |
-| Understand why a design was chosen | [Architecture decision records](docs/README.md#架构决策索引) |
-| Check release evidence and remaining validation limits | [Status and validation](docs/status.md) |
-| Change the framework itself | [Contributor guidance](AGENTS.md) and [focused reading paths](docs/README.md#重构的最短阅读路径) |
+| Implement services, configure modules, or operate the database | [Development and operations](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/development.md) |
+| Understand ownership, lifecycle, transaction, and failure guarantees | [Architecture and contracts](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/architecture.md) |
+| Understand why a design was chosen | [Architecture decision records](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/README.md#架构决策索引) |
+| Check release evidence and remaining validation limits | [Status and validation](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/status.md) |
+| Change the framework itself | [Contributor guidance](https://github.com/componet-architecture/python-ddd-framework/blob/main/AGENTS.md) and [focused reading paths](https://github.com/componet-architecture/python-ddd-framework/blob/main/docs/README.md#重构的最短阅读路径) |
 
 Generated applications include a self-contained English README, `AGENTS.md`, architecture document, and development guide for their template version. `AGENTS.md` directs Codex and other contributors to the affected guidance and module README. Each document has a distinct owner, and the application maintains them after generation; framework upgrades do not overwrite them.
 
 ## License
 
-Python DDD Framework is distributed under the [hank-repo Proprietary License](LICENSE). Use requires a separate written agreement; public package availability does not grant additional rights. The source repository is private, with public PyPI packages as the intended delivery channel. PgQueuer-derived code retains its [upstream license](src/python_ddd_framework/background_jobs/pgqueuer/UPSTREAM_LICENSE.txt).
+Python DDD Framework is distributed under the [hank-repo Proprietary License](https://github.com/componet-architecture/python-ddd-framework/blob/main/LICENSE). Use requires a separate written agreement; public package availability does not grant additional rights. The source repository is private, with public PyPI packages as the intended delivery channel. PgQueuer-derived code retains its [upstream license](https://github.com/componet-architecture/python-ddd-framework/blob/main/src/python_ddd_framework/background_jobs/pgqueuer/UPSTREAM_LICENSE.txt).

{python_ddd_framework-0.3.1.dist-info → python_ddd_framework-0.3.2.dist-info}/RECORD

@@ -347,9 +347,9 @@ python_ddd_framework/unit_of_work/contracts.py,sha256=9SEa4tv2zhrOo5q2h1eCaHKE8l
 python_ddd_framework/unit_of_work/errors.py,sha256=apyOAtdoLNsCuxsaQr5S3v5WxyqrCBAhcMiqxw_kSxk,734
 python_ddd_framework/unit_of_work/manager.py,sha256=sKrRwb1MeECdgtxs0ci-SbAkl4ZGKOyM7mNXClh5nGA,8188
 python_ddd_framework/unit_of_work/options.py,sha256=Xt4ddSZxb3VKfiXV1KWMa4z46FIPFzLyrVwLsM1lMlg,3110
-python_ddd_framework-0.3.1.dist-info/licenses/LICENSE,sha256=2sSWLZdtk4EhG2GlwpksXzmyux-G6Qiov0D27lE_bqw,805
-python_ddd_framework-0.3.1.dist-info/licenses/src/python_ddd_framework/background_jobs/pgqueuer/UPSTREAM_LICENSE.txt,sha256=0lCGUd5Pke2Up1Kqn1kRnHcwLlBz60E8xvR7WL4k_kE,1066
-python_ddd_framework-0.3.1.dist-info/WHEEL,sha256=_d8F1e7SqtoW6CDj4Gi8lFC26a_7I17R7zPLCKTp4Fg,81
-python_ddd_framework-0.3.1.dist-info/entry_points.txt,sha256=CMy4XBD8IKGUfHwe0YBmHmSJtjfnA3yyDHqsMZCLsc8,447
-python_ddd_framework-0.3.1.dist-info/METADATA,sha256=WeApRjzaaRHROdikrevNzOGr7Kc2uH_yV1JlLRBsBA8,30933
-python_ddd_framework-0.3.1.dist-info/RECORD,,
+python_ddd_framework-0.3.2.dist-info/licenses/LICENSE,sha256=2sSWLZdtk4EhG2GlwpksXzmyux-G6Qiov0D27lE_bqw,805
+python_ddd_framework-0.3.2.dist-info/licenses/src/python_ddd_framework/background_jobs/pgqueuer/UPSTREAM_LICENSE.txt,sha256=0lCGUd5Pke2Up1Kqn1kRnHcwLlBz60E8xvR7WL4k_kE,1066
+python_ddd_framework-0.3.2.dist-info/WHEEL,sha256=_d8F1e7SqtoW6CDj4Gi8lFC26a_7I17R7zPLCKTp4Fg,81
+python_ddd_framework-0.3.2.dist-info/entry_points.txt,sha256=CMy4XBD8IKGUfHwe0YBmHmSJtjfnA3yyDHqsMZCLsc8,447
+python_ddd_framework-0.3.2.dist-info/METADATA,sha256=iHiV1JQ518EnyWbRWhoaAasyQ_unx7Ertvq9d6TBlkQ,32703
+python_ddd_framework-0.3.2.dist-info/RECORD,,