fix(commercial): fail closed on workflow registry ambiguity

[seonghobae]

Scope

Hardens the read-only Actions workflow-registry evidence used by Commercial Readiness. The current lineage repairs eighteen fail-open classifications plus five false-blocking detector/runtime defects against the registry/tree/default-branch contract.

Current protected base: main@b84751674dd92bdcd0e266c7f002cdc43f5a938b. Current exact head: b707d65575c4c5ad38630d017572ec43be8f7b2b.

Repaired evidence boundaries

The detector now fails closed on unknown workflow states; present-but-disabled or protected-tree-missing registry identities; duplicate repository/dynamic identities; truncated, mismatched, symlinked, non-blob, malformed-SHA, duplicate-path, and Unicode-candidate Git-tree ambiguity; undocumented non-repository workflow paths; inconsistent pagination; registry mutations across repeated complete scans; malformed/non-canonical timestamps; default-branch/tree/head TOCTOU windows; and late registry drift after final default-branch metadata revalidation. Git-valid % and hierarchical / default-branch names remain accepted through encoded branch API segments.

The protected-tree collector now treats only direct .github/workflows/*.yml|yaml children as workflow candidates. YAML stored in subdirectories such as .github/workflows/archive/ci.yml is not an Actions workflow and no longer false-blocks registry evidence merely because it is below the workflows directory.

The only retained dynamic Actions path is GitHub's documented Dependabot identity dynamic/dependabot/dependabot-updates; it is not inferred from names.

Latest RED → causal repair

RED 69fc5ed3bb372c25ec05bbc58f8a9c1745010def adds a realistic protected-tree fixture containing .github/workflows/archive/ci.yml with an otherwise empty Actions registry and requires snapshot collection to succeed with zero workflows. The predecessor candidate predicate ^\.github/workflows/[\s\S]*\.ya?ml$ selects that nested YAML, then the strict workflow-path validator rejects it, so the pre-fix control flow is deterministically RED.

GREEN 8b1486a67b32cfdb289d44f018557e7db85bf08a narrows candidate discovery to direct children with ^\.github/workflows/[^/]*\.ya?ml$. Direct workflow files retain the existing strict path/type/mode/blob-SHA validation; unrelated nested YAML is ignored rather than misclassified as workflow evidence.

Current-head test-harness repair

Fresh review of 8b1486a6... found one stale pre-existing fixture in workflow-registry.test.mjs: the complete-pagination happy-path supplied .github/workflows/ci.yml with type: blob and mode: 100644 but no blob SHA. Since the production collector now intentionally rejects missing workflow blob identity, that nominal happy-path was deterministically RED before registry pagination could be validated.

fdda5f86df359940d6076889a0e840ee4ebe8162 adds the exact 40-hex fixture SHA and changes no production logic. A bounded Node reproduction of the current tree-entry contract rejects the predecessor fixture with GitHub workflow tree entry blob SHA is invalid and accepts the repaired fixture as .github/workflows/ci.yml.

Fresh review then found the same happy-path still asserted the pre-hardening request count/order even though production now performs three complete registry reads and a confirmed final default-branch head read. The old assertions expected four workflow-page requests and ended at branch -> repository, while the current implementation deterministically emits six workflow-page requests and finishes branch -> repository -> final registry page 1 -> final registry page 2 -> confirmed branch. A bounded Node reproducer is RED against the old expectations and GREEN against the corrected sequence. b707d65575c4c5ad38630d017572ec43be8f7b2b updates only those harness assertions; production logic is unchanged.

Local repository execution remains unavailable because this runtime cannot resolve github.com; hosted exact-head workflows remain the repository-wide acceptance evidence and are not yet GREEN.

Protected-main adoption

The branch previously adopted #239 non-destructively because its workflow-trigger delta was path-disjoint from this package.

Protected main then advanced through #240 to b84751674dd92bdcd0e266c7f002cdc43f5a938b, reverting unsafe docs-only skipping in LifeOS CI and Commercial Readiness. #230 does not own those workflow files. Current exact head b707d65575c4c5ad38630d017572ec43be8f7b2b remains an ahead-only descendant of current protected main.

No predecessor workflow or review evidence transfers.

Control-plane boundary

Issue #202 remains the owner for actual orphan workflow-state mutation. This PR classifies read-only evidence only; it does not introduce a PAT, restore historical YAML, grant broad scanner mutation authority, or create a self-deleting cleanup workflow. Proven active orphan identities still require fresh exact-state revalidation plus an authorized disable operation.

The live organization ruleset currently requires one approving review, review-thread resolution, and nine required workflows owned by ContextualWisdomLab/.github@main: close-empty-pr.yml, opencode-review.yml, pr-review-merge-scheduler.yml, security-scan.yml, strix.yml, sast-semgrep.yml, noema-review.yml, scorecard-pr.yml, and osv-scanner-pr.yml. Keep Draft until the unchanged exact head has terminal applicable repository and organization-required workflow evidence, actionable review findings are resolved, and that live policy is satisfied. No self-approval, administrator bypass, force-push, or predecessor evidence reuse.

Refs #202, #240.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}