test(install): align shared-file ownership expectation

[danielmeppiel]

fix(release): align shared-file cleanup test with single-owner lockfiles

TL;DR

The v0.24.1 tag workflow exposed a stale integration assertion: the test still expected two packages to claim one deployed path, although #2052 intentionally made ownership single-writer. This PR requires pkg-b, the last writer, to be the sole lockfile owner while preserving the existing cleanup behavior checks. The correction unblocks release validation without changing production behavior.

Important

This is the deterministic failure from v0.24.1 release run 29093268394; no GitHub Release or PyPI publication occurred.

Problem (WHY)

• TestCrossPackageSharedFileCleanup required two lockfile entries to claim .github/prompts/shared.prompt.md.
• fix(skills): key ownership tracking on owner/repo, not the leaf directory name #2052 intentionally reconciles duplicate claims to one last-writer owner; the v0.24.1 changelog records that colliding packages no longer "claim the same deployed files."
• The stale assertion failed identically in macOS arm64, macOS x86_64, and Linux x86_64 release jobs, preventing Release Validation and every publication job from running.

Why this matters: release evidence must match the shipped lockfile contract. "Grounding outputs in deterministic tool execution transforms probabilistic generation into verifiable action."

Approach (WHAT)

#	Fix	Principle	Source
1	Require the shared prompt's owner-name set to equal {"pkg-b"}.	Governed by policy	#2052
2	Keep the subsequent reinstall and stale-file cleanup assertions unchanged.	DevX (pragmatic as npm)	test_intra_package_cleanup.py

Implementation (HOW)

• tests/integration/test_intra_package_cleanup.py -- replaces the obsolete duplicate-owner count with an exact assertion that pkg-b, the last writer in the manifest order, is the only package claiming the shared prompt. Production lockfile and cleanup code are deliberately untouched.

Diagrams

Legend: the dashed node is the corrected assertion; the install and cleanup flow remains unchanged.

flowchart LR
    subgraph Install[Initial install]
        A[pkg-a writes shared prompt]
        B[pkg-b writes shared prompt]
    end
    subgraph Lockfile[Lockfile reconciliation]
        C[Last writer owns path]
    end
    subgraph Test[Integration assertion]
        D["Owner names equal pkg-b"]
        E[Remove pkg-a prompts]
        F[Shared survives and only-a is removed]
    end
    A --> C
    B --> C
    C --> D
    D --> E
    E --> F
    classDef new stroke-dasharray: 5 5;
    class D new;

Loading

Trade-offs

• Correct the test, not production. Chose to align the assertion with fix(skills): key ownership tracking on owner/repo, not the leaf directory name #2052's single-owner contract; rejected restoring duplicate ownership because that would reintroduce stale lockfile claims.
• Retain end-to-end coverage. Chose an exact owner-name assertion and the existing real CLI reinstall; rejected mocking reconciliation because it would weaken the release-boundary regression test.

Benefits

1. All three release jobs that hit this assertion can evaluate the intended single-owner contract.
2. The test now verifies exactly one owner, pkg-b, rather than only checking a count.
3. The cleanup regression still proves the shared prompt survives while the unclaimed only-a prompt is removed.

Validation

uv run --extra dev pytest -q tests/integration/test_intra_package_cleanup.py::TestCrossPackageSharedFileCleanup::test_shared_file_survives_when_other_package_still_deploys_it:

.                                                                        [100%]
1 passed in 2.09s

uv run --extra dev pytest -q tests/integration/test_intra_package_cleanup.py:

...                                                                      [100%]
3 passed in 4.14s

CI lint mirror

.agents/skills/cut-release/scripts/verify-lint-mirror.sh:

ruff check                     PASS
ruff format --check            PASS
pylint R0801 duplication       PASS
auth-signals boundary          PASS
all lint-mirror checks PASSED

Scenario Evidence

#	Scenario (user promise)	Principle(s)	Test(s) proving it	Type
1	When two packages deploy the same prompt, the last writer is the sole recorded owner and its file survives another package dropping its copy.	Governed by policy, DevX (pragmatic as npm)	tests/integration/test_intra_package_cleanup.py::TestCrossPackageSharedFileCleanup::test_shared_file_survives_when_other_package_still_deploys_it (regression-trap for release run 29093268394)	integration

How to test

• Run the targeted cross-package cleanup test; observe one pass.
• Run the complete test_intra_package_cleanup.py file; observe three passes.
• Run the CI lint mirror; observe all four gates pass.
• Re-run the tag workflow after merge; observe Release Validation and publication jobs proceed.

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

[danielmeppiel]

Docs sync advisory

Verdict: no_change * Pages affected: 0 * LLM calls: 0/15 * Took: <1s

No docs impact detected. Reason: L0 path gate matched a test-only change under tests/**; no user-observable command, schema, authentication, policy, or primitive format changed.

[Copilot]

Pull request overview

Updates an integration regression test to match the post-#2052 lockfile contract where cross-package shared deployed paths are reconciled to a single (last-writer) owner, aligning release validation expectations without changing production behavior.

Changes:

• Replace the stale “two packages claim shared file” assertion with an ownership assertion aligned to single-writer reconciliation.

Show a summary per file

File	Description
tests/integration/test_intra_package_cleanup.py	Updates the shared-file ownership assertion to reflect single-owner lockfile reconciliation behavior.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Low

[danielmeppiel]

Release-blocking hotfix: v0.24.1 publication is paused because the tag workflow exposed this stale single-owner assertion. All PR checks are green; requesting code-owner approval so the merge queue can proceed.