Skip to content

Triage zero-job startup failures during scanner canary #991

Open

Description

@hyperpolymath

Please triage workflow startup separately from scanner findings. unified-dataset-vocab PR #81 head 5fdfb6a83d366450e222000ded22e28144b46419 scanner run 41198606402 passed all three contexts, while governance run 41198606103 and Hypatia run 41198606102 completed with zero jobs. Fleet main scanner run 40933665219 also had zero jobs. These observations do not establish the cause; please inspect admission and lock validation with an owner and share non-secret diagnosis before rollout expands.

Activity

  1. added
    researchOpen investigation; the outcome is knowledge, not code
    on Oct 31, 2026
  2. coderabbitai commented on Oct 31, 2026

    @coderabbitai
    Contributor
    🔗 Related PRs

    #988 - ci: canary direct, pinned cicd-squabbler chains gate [closed]
    #958 - fix(ci): re-point standards callers to metadatastician/standards [merged]


    📝 Issue Planner

    Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.

    • Create Plan

    🧪 Issue enrichment is currently in open beta.

    You can configure auto-planning by selecting labels in the issue_enrichment configuration.

    To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

    issue_enrichment:
      auto_enrich:
        enabled: false

    💬 Have feedback or questions? Drop into our discord!

  3. added
    cicdCI/CD: workflows, actions, lockfiles, pins, runners, release gates
    governancePolicy, rulesets, standards, compliance, and their enforcement
    on Oct 31, 2026
  4. hyperpolymath commented on Nov 4, 2026

    @hyperpolymath
    OwnerAuthor

    Concrete migration experiment from the 2026-11-04 assurance audit (retained, then reverted): proven-tests-and-benches commit 6c1c567bfc1d0bc822cade87f62cde25a2a8bc23 and panic-attack commit 6addd22f2f0ce36baf57fde94cd4009ccf021e3e changed only the three thin callers' Standards owner paths to metadatastician/standards and used cicd-suite's tested deonboarding script on their lock entries. Existing full callee SHAs, job identifiers and permission grants were retained; the callee files were readable at those SHAs under the new owner.

    All six reusable runs still startup-failed: Proven Tests 41816608637 / 41816607227 / 41816605793; panic 41816637511 / 41816636052 / 41816634641. Consumer CI then caught a second incompatibility: Proven run 41816604331 rejects three workflows with no lock entries, and panic CI Integrity 41816632936 rejects the lock as no longer generator-derived.

    This means the suite's deonboarding procedure is not a complete migration for these consumers. The experiment was reverted; neither integrity check was weakened. A coordinated resolution needs the consumer lock/generator contract, callee transitive lock state, transferred owner and actual Actions admission settings. Administration settings are not available through the current connection, so no specific unseen allowlist value is asserted as the sole cause.

    Repair and evidence PRs: hyperpolymath/proven-cicd-and-workflows#77, hyperpolymath/proven-tests-and-benches#103, hyperpolymath/panic-attack#257. Startup-refused lanes must remain unavailable/void, not green or a successful neural repair outcome.

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

    cicdCI/CD: workflows, actions, lockfiles, pins, runners, release gatesgovernancePolicy, rulesets, standards, compliance, and their enforcementresearchOpen investigation; the outcome is knowledge, not code

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions