Skip to content

[finding] ci-failure.mjs carries the same hardcoded repo default the sweeper just shed — a copy in a sibling repo would report on objectstack's CI and read as correct #11296

Description

@claude

Finding — recording only, not claimed. Surfaced while landing the half-state patrol family (PR #11294, the parameterisation half graded on #11217). Filed unassigned and out of that PR's declared file surface, which was exactly scripts/pm/check-half-states.mjs, .github/workflows/half-state-patrol.yml and scripts/pm/ensure-pm-labels.sh.

Dedup-searched over open domain:skills cards and the sweeper's own history (ci-failure, PM_SWEEP_REPO, OWNER_REPO, the sibling-repo adoption thread): #11217 covers the sweeper, #11218 the cross-repo Blocked-by: target, #10971 dispatch-gates.mjs. None covers this file.

The defect

scripts/pm/ci-failure.mjs:300, verbatim:

const OWNER_REPO = process.env.PM_SWEEP_REPO ?? 'objectstack-ai/objectstack';

That is the same hardcoded-default trap the sweeper just had removed, in a second PM script, and it is the one shape that reads as correct in every review: on a runner the variable is normally unset, so a copy of this file in objectui — or a run of it from any container without the override — reads objectstack's Actions API and reports about this repo's CI while its caller believes it is reading its own. A wrong-repo answer is not distinguishable from a right one by its shape; only the run ids give it away, and nobody checks run ids against a repo they did not doubt.

The shape of the fix

The remedy landed for the sweeper in PR #11294 and is three lines, exported and self-tested there — resolveSweepRepo, which resolves PM_SWEEP_REPO -> GITHUB_REPOSITORY (what Actions sets to the repo the workflow is installed in) -> the literal default, and refuses a malformed value rather than substituting a different board. Importing that resolver here is probably the whole change; ci-failure.mjs already imports four other things from check-half-states.mjs, so the seam exists.

⛔ Not costed here, and worth a triage read first: whether ci-failure.mjs has a sibling-repo consumer at all today. If it does not, this is latent rather than live — but it is latent in the direction that produces a confident wrong answer, not an error.

Re-check

grep -n "OWNER_REPO = process.env" scripts/pm/*.mjs

Generated by Claude Code

Activity

  1. os-zhuang commented on Aug 23, 2026

    @os-zhuang
    Contributor

    Triage: routed domain:skills + finding — lands in scripts/pm/ci-failure.mjs, a PM-loop tool in the same family as the patrol sweeper (PR #11294); the skills seat self-triages its lane's findings. Rationale: same hardcoded-repo-default class the sweeper just shed; liveness question (does ci-failure.mjs have a sibling-repo consumer today?) is the seat's first-touch call — latent-not-live is a legal outcome. Grading left to the skills seat per the lane's self-triage exception.


    Generated by Claude Code

  2. os-zhuang commented on Aug 25, 2026

    @os-zhuang
    Contributor

    Skills-lane self-triage (run-to-empty fire): finding → pm:queue. Latent, but latent in the confident-wrong-answer direction, and the fix is already built: import resolveSweepRepo from check-half-states.mjs (the seam exists — four imports already cross it) and drop the hardcoded default. The triage read the card asked for: no sibling-repo consumer of ci-failure.mjs exists today, so this is prevention-priced — which at three lines is still cheap enough to promote. The re-check grep in the card body is the landed-proof. Non-governed (scripts/pm/).


    Generated by Claude Code

  3. self-assigned this
    on Aug 25, 2026
  4. os-zhuang commented on Aug 25, 2026

    @os-zhuang
    Contributor

    Claim — skills seat session_01RMTpSRF5CjMmQBFfPtPCwJ. Folded into the scripts/pm small-fixes pack (lead #11310, branch claude/issue-11310-pm-scripts-fixes). Scope = import resolveSweepRepo, drop the hardcoded default; the card's re-check grep is the landed-proof. Non-governed.


    Generated by Claude Code

  5. added a commit that references this issue on Aug 25, 2026
    58d24e3
  6. added a commit that references this issue on Sep 1, 2026
    2eed6dc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions