[Eduard van Valkenburg (eavanvalkenburg)]

Motivation & Context

The package-management guidance currently couples Beta promotion to inclusion in agent-framework-core[all]. That makes lifecycle maturity a proxy for standard-install membership and would automatically expand the meta-package as specialized storage backends, hosting adapters, and other integrations mature.

This change makes lifecycle, meta-package membership, and lazy-loading exposure explicit, independent decisions while preserving the sample relocation and import-surface work that accompanies promotion.

Description & Review Guide

• What are the major changes? The package-management skill now defaults new packages to exclusion from the standard install set, defines criteria and issue/core-team approval requirements for both additions and removals, and requires every promotion issue to record the lifecycle transition and meta-package decision. Lazy-loading namespaces are selected at Alpha→Beta, then preserved by default at Beta→RC and RC→Released. Objects owned by a prerelease package may still be added, removed, or moved between approved namespaces by explicit core-team decision, but a namespace module itself may be removed only when it is empty and serves exclusively unreleased packages. Released object paths require forwarding compatibility or explicit migration, breaking-change, and Core/root version treatment. PACKAGE_STATUS.md tracks meta-package membership independently from lifecycle. Duplicated package-creation, promotion, versioning, and dependency-bound rules were removed from CODING_STANDARD.md; it and the feature-lifecycle guidance now refer to the package-management skill as the normative source. The API compatibility parser and its tests accept the additional status-table column, and the root package description calls the install set curated rather than comprehensive.
• What is the impact of these changes? Future Beta, RC, and released promotions no longer expand core[all] automatically. Sample moves and approved lazy imports still occur during promotion. Later promotions normally retain their established namespace while preserving prerelease flexibility for newly exposed objects without silently deleting a stable Core namespace. Removing an existing meta-package member requires explicit compatibility, migration, breaking-change, and versioning consideration. Existing meta-package membership is unchanged.
• What do you want reviewers to focus on? Whether the inclusion/removal criteria, promotion-issue decision record, namespace-module compatibility boundary, and default namespace-preservation rules are sufficiently explicit, and whether PACKAGE_STATUS.md is the right source of truth for membership.

Related Issue

N/A - draft pending an agreed issue. Link the packaging-policy issue before marking this PR ready for review.

AI Assistance

• No material AI assistance was used.
• This is an AI-assisted contribution. I reviewed, understood, and verified all submitted content and accept responsibility for it.

AI assistance details: Packaging guidance, status-table/parser updates, tests, documentation consolidation, and this PR description.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR links to an agreed issue with no competing open PR, or the Related Issue section documents a trivial-change or repository-automation exception.
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

[Copilot]

🟡 Changes recommended

The changes are internally consistent, but the required agreed packaging-policy issue has not yet been linked.

0 open findings

What changed in this PR

Clarifies that Python package lifecycle, meta-package membership, and lazy-loading exposure are independent decisions.

Changes:

• Defines explicit meta-package inclusion criteria and promotion requirements.
• Adds membership tracking to PACKAGE_STATUS.md.
• Updates compatibility parsing, tests, and package description.

File	Description
python/​pyproject.toml	Describes the optional integrations as curated.
python/​PACKAGE_STATUS.md	Tracks meta-package membership separately.
python/​.github/​skills/​python-package-management/​SKILL.md	Documents the revised promotion policy.
.github/​scripts/​check_python_api_compatibility.py	Accepts the additional status column.
.github/​tests/​test_python_api_compatibility.py	Tests old and new status-row formats.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

MAF Automated Review — Iteration 1

Result: No findings
Scope: full PR (1 commit(s)): 8707bb8c217a
Model: gpt-5.6-sol

Overview

The PR separates package lifecycle, meta-package membership, and lazy-loading decisions while preserving the existing install set. The updated status table matches core[all], and the compatibility parser retains support for both the legacy and new table shapes with targeted tests. No concrete Critical, High, or Medium regression remains after reconciling the proposed failure cases against the current table format and package metadata.

Reviewed the supplied pull-request change set across correctness, security/reliability, architecture, and failure behavior.
No publishable findings remained after source verification for this scope.

[Jose Alvarez (jpalvarezl)]

A few policy consistency points.

[github-actions]

MAF Automated Review — Iteration 2

Result: Findings reported
Scope: 3 net-new commit(s): 91403f95e027, f56b6873d1f3, 2866aad2a531
Model: gpt-5.6-sol

Overview

The change cleanly separates package lifecycle, meta-package membership, and lazy-loading exposure, with explicit issue and core-team approval gates and conservative defaults. The status parser and release guidance remain compatible with the new source-of-truth structure. One compatibility gap remains: later promotions may move or remove a public namespace without requiring migration, breaking-change, or versioning treatment.

Reviewed the supplied incremental change set across correctness, security/reliability, architecture, and failure behavior.
1 verified finding remained after source verification (1 medium) across 1 file. Details are attached to the affected lines below.

Affected areas: python/.github/skills/python-package-management/SKILL.md

[Jose Alvarez (jpalvarezl)]

The follow-up commits address my three inline comments and the later namespace-compatibility feedback. I have no additional code or policy findings. I am leaving this as a comment rather than approval because the previously raised agreed-issue/link requirement is still outstanding.