[Fleet Monitor] petry-projects/.github-private — .github/workflows/feature-ideation.yml #1354

Activity

1. don-petry

   added

   health-checkAutomated health check reportAutomated health check report

   dev-leadFor dev-lead agent pickupFor dev-lead agent pickup

   fleet-trackerTracked by the Actions Fleet MonitorTracked by the Actions Fleet Monitor

   on Jul 22, 2026
2. don-petry commented on Jul 22, 2026

   

   don-petry

   on Jul 22, 2026

   CollaboratorAuthor

   More actions

   Dev-Lead Implementation Plan

   Issue: #1354 — [Fleet Monitor] petry-projects/.github-private — .github/workflows/feature-ideation.yml

   Scope

   Investigate the 50% failure rate of feature-ideation.yml and determine the correct fix location.

   Investigation findings

   • The failing runs are workflow_dispatch / schedule (fast ~17–21s). discussion runs pass because they only execute the local redispatch job and never call the reusable.
   • The failing step is inside the reusable feature-ideation-reusable.yml (hosted in petry-projects/.github, pinned here via the sanctioned @feature-ideation/v1-next ring channel): ideate / Gather Project Signals → Install Python jsonschema:

     ERROR: Could not open requirements file: [Errno 2] No such file or directory:
     '.feature-ideation-tooling/scripts/feature-ideation-requirements.txt'
     

   • Root cause: the reusable checks out its tooling from petry-projects/.github at tooling_ref (default v1). scripts/feature-ideation-requirements.txt is 404 at the v1 tag but present at main and feature-ideation/v1-next. The v1 tooling tag is stale / was never moved forward.

   Conclusion — no in-repo change is correct

   This repo holds only the thin caller stub, which is drift-free with the org template (tests/test_feature_ideation.bats passes; repo lint passes). The defect is entirely in the cross-repo reusable / its v1 tooling tag.

   The tempting workaround — forwarding tooling_ref: from this stub to override the broken v1 default — is rejected:

   • The org template stub does not forward tooling_ref; adding it would create template drift (flagged by the template-drift / stub-drift guards) and violate thin-caller-stub minimalism.
   • It would only mask the stale-tag defect for this one consumer while every other feature-ideation consumer stays broken.

   Exempting the workflow from Fleet Monitor (FLEET_GATE_WORKFLOWS) is also rejected — this is a real failure, not intentional gate enforcement.

   Required fix (cross-repo, petry-projects/.github)

   Move the v1 tag forward to a commit that includes scripts/feature-ideation-requirements.txt (the reusable's own docs assume v1 tracks releases), or fix the reusable's tooling_ref default. Out of scope for this repository.

   Test Command

   bats tests/test_feature_ideation.bats (+ bash .dev-lead/scripts/dev-lead-lint.sh)
3. don-petry commented on Jul 22, 2026

   

   don-petry

   on Jul 22, 2026

   CollaboratorAuthor

   More actions

   Dev-Lead: Investigation Complete — No In-Repo Fix (Cross-Repo Root Cause)

   Root cause

   The DEGRADED status is caused by a defect in the cross-repo reusable, not this repo's caller stub.

   Failing workflow_dispatch/schedule runs die in the reusable
   feature-ideation-reusable.yml (petry-projects/.github, pinned via the sanctioned
   @feature-ideation/v1-next ring channel) at ideate / Gather Project Signals → Install Python jsonschema:

   Run pip install --quiet --require-hashes --only-binary :all: -r .feature-ideation-tooling/scripts/feature-ideation-requirements.txt
   ERROR: Could not open requirements file: [Errno 2] No such file or directory: '.feature-ideation-tooling/scripts/feature-ideation-requirements.txt'
   ##[error]Process completed with exit code 1.
   

   The reusable checks out its tooling from petry-projects/.github at tooling_ref (default v1).
   scripts/feature-ideation-requirements.txt is 404 at tag v1 but present at main and
   feature-ideation/v1-next — the v1 tooling tag is stale / was never advanced to a release carrying
   the requirements file. discussion runs pass because they only execute the local redispatch job and
   never invoke the reusable (matching the observed 50%: dispatch/schedule fail, discussion succeeds).

   Decision — no changes to .github-private

   This repo holds only the thin caller stub, which is drift-free with the org template and correct.
   No source change here can fix a stale tag in another repo, and the tempting workarounds are guardrail
   violations:

   • Forwarding tooling_ref: from the stub to override the broken v1 default — rejected. The org
     template does not forward it, so this creates template drift (template-drift / stub-drift guards)
     and violates thin-caller minimalism, while masking the defect for only this one consumer.
   • Exempting the workflow via FLEET_GATE_WORKFLOWS — rejected. This is a real failure, not
     intentional gate enforcement; suppressing it would hide the bug.

   Required fix (out of scope — petry-projects/.github)

   Move the v1 tag forward to a commit that includes scripts/feature-ideation-requirements.txt (the
   reusable's tooling_ref docs assume v1 tracks releases), or correct the reusable's tooling_ref
   default. Recommend opening a tracking issue against petry-projects/.github.

   Verification (this repo)

   $ bats tests/test_feature_ideation.bats
   1..15
   ok 1..15  (all pass)
   
   $ bash .dev-lead/scripts/dev-lead-lint.sh
   [lint] shellcheck on 98 file(s)...
   [lint] validating 4 agent profile(s)...
   [lint] all checks passed
   

   Files Changed

   • None. Root cause is cross-repo; the in-repo stub is correct and drift-free.

   Phase 2 (TDD) note

   Skipped per the documented exception — there is no in-repo behavioral change to test. Existing
   tests/test_feature_ideation.bats already pins the stub's drift-free contract and stays green.

   Notes

   No in-repo action is appropriate. Fix must land in petry-projects/.github (stale v1 tooling tag).
4. don-petry commented on Jul 26, 2026

   

   don-petry

   on Jul 26, 2026

   CollaboratorAuthor

   More actions

   ✅ Auto-resolved by Fleet Monitor. This workflow's failure rate has been below the 10% threshold (or the workflow was removed) since 2026-07-23 (3 days) — the monitor stopped flagging it. Closing. It will reopen automatically if the workflow crosses the threshold again.
5. don-petry

   closed this as completedon Jul 26, 2026