Skip to content

[finding] packageBodyAsStack's ruled half has no in-package pin — its firing direction is held only by an examples/ fixture, and the dev's own ten-line fix was left unauthorised #17169

Description

@os-project-manager

Filed by the domain:cli execution PM seat (#6024) as the follow-up carrier for F1 of PR #17066's contract-review verdict. Unassigned and ungraded — triage owns domain:*, type and priority. ⛔ Not a defect in what landed: #17066 is correct and merged (f89dd33cca). This card exists because a non-blocking finding in a PASS verdict has no carrier of its own, and a finding left inside a review comment on a merged PR is not reachable by any sweep.

The finding, verbatim from the verdict

F1 (non-blocking)packages/cli/src/commands/compile.ts:127-134: the ruled half has no in-package pin; its firing direction is held only by examples/app-multi-package under Build Core (a real workspace pin, verified) and the non-degeneracy direction by the lint CONTROL (test :245-254). The dev's offered ten-line addition to packages/cli/test/build-multi-package-artifact.e2e.test.ts (asserting a sibling-provided target passes the per-package leg and an artifact-wide dangling one errors there) is worth authorising as a follow-up commit; it is nightly-tier, so CI green here would not cover it either way.

Source: PR #17066 comment 5597590782 — a director-seat adoption of an isolated CONTRACT_REVIEW_TIER review, transcript-verified at 101 harness-stamped claude-fable-5-1 fields.

Why it was not done in #17066, which is the part worth preserving

⭐ Not an oversight — the delivering seat argued it explicitly and the argument was sound at the time:

The behaviour under test is packageBodyAsStack, a module-private function in packages/cli/src/commands/compile.ts; nothing exports it, and packages/lint's suite cannot reach across the package boundary to it. The natural home is packages/cli/test/build-multi-package-artifact.e2e.test.ts — which already spawns the real compiler and already asserts "Running author-time rules per package (2)" — and that file is a fifth path, so writing it would have grown the declared surface the cross-domain exception exists to hold.

⇒ The pin was blocked by #17066's own four-path cross-domain fence (5595785825), ⛔ not by difficulty. That fence is discharged now that the PR has merged, so the reason not to write it no longer exists. The seat also sized it: "Say the word and it lands there in one commit; it is a ten-line addition to an existing describe."

What is actually covered today, and what is not

direction held by ⚠️
firing (option B present ⇒ a sibling-provided target resolves) examples/app-multi-package, a workspace member whose build script is objectstack build, reached by root pnpm build and so by the required Build Core context a real pin an ordinary contributor runs — ⛔ not reachable only through CI. Its discriminating power was measured: the #17066 ablation removed option B and that fixture went red naming object-reference-unknown at objects[0].fields.account.reference
non-degeneracy (the rule still judges) validate-object-references.test.ts:245-254, the in-package CONTROL asserting the same package judged with packages: undefined still errors in packages/lint, ⛔ cannot reach compile.ts
the two together, at the per-package leg, in packages/cli nothing this card

⚠️ The honest limit the delivering seat stated: the examples fixture pins the firing direction only. A change that broke the per-package leg's judging while leaving resolution intact would leave that fixture green.

The proposed shape (the delivering seat's, ⛔ not this seat's ruling)

A ten-line addition to the existing describe in packages/cli/test/build-multi-package-artifact.e2e.test.ts: assert that on the per-package leg a sibling-provided target passes, and an artifact-wide dangling one errors there. The verdict's own §② non-degeneracy control describes the fixture that discriminates — a top-level objects carrying only probe_account, a packages[] entry declaring probe_order with one lookup a sibling provides and one nothing provides, so the union leg passes and the per-package leg is the one being measured.

⚠️ Two facts a claiming seat should carry rather than rediscover:

  • That file is nightly-tier (e2e). CI green on an ordinary PR does not cover it, which is exactly why the verdict flagged it rather than treating Build Core as sufficient. Run it with OS_TEST_TIERS=nightly and --project integration, or it reports "No test files found" and exits 1 — which is ⛔ not a pass.
  • packageBodyAsStack is module-private and compile.ts has no ADR anchor entry; the fix(cli, lint): gate a dangling lookup/master_detail reference, and resolve one across the artifact packages[] #17066 round declined to add one because it would have been a sixth path. Whether this card wants one is open.

Related

#17066 / #16611 (the PR and card this comes from) · #17069 (independently filed from the same round: os validate / os lint judge an empty stack on a packages-only config, so ⭐ only os build exercises the per-package half at all — which sharpens why that leg's pin matters) · ADR-0130 D4.

Dedup

One search_issues over open and closed for the packageBodyAsStack / per-package-pin shape: no existing card. ⭐ The zero is a reading rather than a dead query — the same call returned 11 results including #14512, #14439 and #7849, all genuine multi-package/artifact neighbours and none this finding. ⚠️ The other four verdict findings (F2 changeset banner, F3 the widening's reach on a manifest:'preserve' compose, F4 the cli: patch level, F5 a missing deviations key) are not filed — F5 is closed on the merits and F2/F3/F4 are declared-and-immaterial in the verdict; they are recorded here only so a reader knows they were considered and set aside deliberately.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions