Improve Open Actions compatibility reviews and implementation guidance

[kelos-bot]

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

Keeps Open Actions agents aligned with full documented GitHub Actions compatibility and incorporates recurring implementation lessons from PR reviews. Shared implementation guidance lives in agentconfig.yaml; the four reviewer configurations carry the corresponding review checks. The final diff touches only those five files under self-development/open-actions/, and shared skills remain in self-development/base-agent.yaml.

• Keep intentional compatibility regressions eligible for review. The implementation review of Open Actions #159 and its API review identified lost trigger reporting, Checks-tab visibility, GitHub rerun controls, and collapsed execution identities. A later #159 review stopped raising the remaining reporting/rerun gaps because they were intentional, documented, and tracked. The #163 API review repeated that reasoning for the narrower newest-execution reporting contract. The merged diffs retain the narrower reporting model. Code-review criteria now allow documented compatibility findings despite author intent or preference, and all four reviewer prompts explicitly check trigger coverage, separate workflow/job reporting, Checks visibility, and GitHub UI/CLI reruns. Shared guidance clarifies that rejection, an alternative, or a tracking issue does not close a gap. Verified against GitHub's current workflow reporting model, Checks versus commit statuses, multiple-event behavior, and rerun contract. Existing compatibility text in the planner, triage, user, strategist, and configuration-update prompts is preserved.

The shared implementation guidance retains these review-backed lessons:

• Treat GitHub commit-status contexts as external identities used by required checks. Reviews: #163, #163, #163, #164, #164.
• Recover accepted external reports after local status persistence fails, for both initial reports and later transitions, and use only the latest report for the identity and expected creator. Reviews: #159, #159, #163, #163.
• Treat persisted and versioned cross-component data as upgrade contracts, preserving in-flight and pre-upgrade data and positively testing current and fallback paths. Reviews: #45, #47, #47, #49, #55, #55.
• Require workflow parsing to reject unsupported or ambiguous input instead of silently ignoring it or applying last-value-wins behavior. Reviews: #1, #1, #1.
• Keep durable repository documentation aligned with observable behavior, supported syntax, enforced limits, and operational prerequisites. Reviews: #3, #3, #13, #54, #54, #62.
• Preserve retryable dependency failures consistently across reconciliation phases and test their observable retry state. Reviews: #64, #64.
• Keep request, reconcile, and retry hot paths bounded by capping or paginating list-backed responses, placing no-op checks before expensive reads, and persisting completed sub-work. Reviews: #52, #47, #70.
• Exercise integration-dependent behavior through the installed Kind path and test security boundaries through their real enforcement layer. Reviews: #53, #55, #73, #74.
• Bound repository-controlled parsing and expression evaluation at every stage: source size, AST depth and node count, incremental evaluation output, and post-interpolation field and aggregate budgets. Reviews: #45, #45.
• Follow GitHub Actions' documented expression coercion and error semantics. Reviews: #74.
• Preserve GitHub API file-type semantics and validate network-sensitive Git behavior with realistic remotes. Reviews: #77.
• Retain positive authorization coverage for every supported credential path and keep deployed credential wiring covered end to end. Reviews: #78.
• Version every controller-to-runner interface, including job plans, CLI arguments, environment variables, mounted files, and credentials, and test both skew directions. Reviews: #79, #79, #93.
• Bound combinatorial traversal independently of accepted output so filters cannot hide unbounded work. Reviews: #95, #45.
• Keep PR descriptions and release notes as accurate as repository documentation, including changed defaults, upgrade requirements, and access boundaries. Reviews: #79, #94, #94.
• Preserve positive coverage for each distinct production path when repurposing tests or fixtures. Reviews: #78, #91.
• Make create-and-follow-up workflows retry-safe across stale caches, concurrent reconciles, and partial failures. Reviews: #108, #93, #92.
• Compare omitted and operator-configured behavior across every resource-creation path before adding optional API or configuration fields. Reviews: #105, #105, #92, #96, #96.
• Preserve scalar meaning and matrix identity across workflow YAML, expression results, webhook JSON, and persisted intermediate data. The #95 review found numeric values changing representation after deferred-plan serialization; the #169 review finds the same class of mismatch between expression-produced float64 values and reloaded json.Number values, rejecting selective reruns even though YAML-literal tests pass. The shared rule requires consistent, value-preserving identity normalization and separate coverage of YAML literals and fromJSON numeric matrices through planning, persistence/restart, and selective reruns, including large integers and small fractions. GitHub documents numeric expressions and fromJSON, matrices from job outputs, and selective reruns; the internal representation mismatch is therefore a compatibility gap. Related earlier review: #93.
• Define concurrency order independently of reconcile arrival and intermediate status presence, and test adversarial arrival sequences. Reviews: #102, #104.
• Treat condition-reason tables and supported expression/result lists as exhaustive documentation contracts. Reviews: #104, #107, #100.
• Handle permanently missing referenced state according to its lifecycle. Reviews: #89, #94, #95.
• Treat the current GitHub Actions documentation as the normative workflow specification and classify every missing or different documented behavior as a compatibility gap. Reviews: #103, #121.
• Preserve independent workflow candidates represented by one webhook. Reviews: #121.
• Classify GitHub rate-limit responses precisely and preserve unrelated aggregated failures. Reviews: #122.
• Preserve the causal meaning of terminal and non-running job states instead of treating status presence or a coarse terminal, cancelled, or skipped predicate as proof of success, reuse, or lifecycle progress. Reviews: #127, #100, #102, #104, #141.
• Exercise every independent validation constraint through the real enforcement layer, including numeric bounds and Kubernetes structural list or map semantics. Reviews: #130, #74.
• Exercise shared behavior through every materially distinct production caller and cover path-specific lifecycle and backing-store assumptions. Reviews: #133, #91, #78.
• Test every ordered source or fallback with distinguishable fixtures and assert which source wins, rather than only checking a final value that another branch can produce. Reviews: #135, #136.
• Do not let conditionally skipped or optional-tool-dependent tests serve as the only coverage of deterministic logic. Reviews: #140, #101.
• Populate phase-sensitive expression contexts from actual execution state at every supported evaluation site instead of substituting optimistic defaults. Reviews: #144.
• Treat runnable examples as maintained contracts that remain executable and continue demonstrating behavior outside the provided baseline. Reviews: #124, #143.
• Match Open Actions' actual structured-logging convention without inventing an initial-capital requirement. Reviews: #150, #150.
• Test exact cross-component textual contracts at both the producer and consumer. Reviews: #149, #140.
• Require feature-specific terminal reasons to be proven by authoritative lifecycle state or field-specific API details. Reviews: #156, #157.
• Scope bearer credentials to the permissions and actual enforced lifetime of the receiving path. Reviews: #156, #79.
• Preserve existing GitHub Actions-compatible paths when replacing a mechanism instead of trading one behavior for another or treating documentation and tracking as permission to regress. Reviews: #159, #159.

Which issue(s) this PR is related to:

N/A

Special notes for your reviewer:

Validation passed: make verify (generated artifacts, formatting, modules, YAML, shell formatting, and go vet), git diff --check, and a scope check confirming only the five intended configuration files differ from the PR base. These are instruction-only changes; runtime unit tests were not rerun. Go temporary files and caches used the workspace volume.

Reviewed both requested recent-PR lists and collected diffs, formal reviews, inline comments, and conversations for 16 PRs active September 1–8, 2026, including open PR #169 at 386664267619e67a0cc8f71cb86db9359ac512b7. None currently carries generated-by-kelos. The September 8 sticky review by kelos-bot[bot] is current at that head, with no formal reviews or inline threads. Its numeric-identity finding matches the current producer, persisted-plan decoder, comparison, and YAML-only numeric fixture; the earlier #95/#93 reviews establish recurrence. Most findings were already covered by this branch, including #169's lifecycle/error-classification finding. PR #164's aggregate-reporting findings were superseded by its final per-job design; only its retained context-collision and migration findings motivate the naming guidance. PR #166's uncertain or optional suggestions and PRs #165/#167's no-findings reviews did not motivate new rules. The recurring acceptance of narrower behavior in #159/#163 was checked against the official documentation, rather than adopted as a product boundary.

Does this PR introduce a user-facing change?

NONE

[gjkim42]

/kelos squash-commits

[kelos-bot]

🤖 Kelos Task Status

Task kelos-squash-commits-issue-comment-0a8b9b2677e8 has succeeded. ✅

[kelos-bot]

Squash complete.\n\nRebased onto origin/main and squashed to a single commit.