Skip to content

feat(adoption): explain profile-bound workflow adaptation recommendations - #78

Open
iperev wants to merge 1 commit into
feat/operator-navigation-qualificationfrom
feat/adaptation-recommendations
Open

iperev wants to merge 1 commit into
feat/operator-navigation-qualificationfrom
feat/adaptation-recommendations

Conversation

@iperev

@iperev iperev commented Oct 12, 2026

Copy link
Copy Markdown
Contributor

Stacked PR 23 — base: #77 (feat/operator-navigation-qualification). Do not merge yet. Review only the top commit.

Context

CI-020 needs workflow-adaptation recommendations under explicit support profiles, including for unmodified workflows. They must explain unknown semantics and the minimal consumer changes, and give agents no authority.

What changed

  • Provisional owner decision D4 (2026-10-11): a closed supportProfileId with one admitted value, github.com/github-actions-static/v5. An unknown profile gives full_only with an explicit support_profile_unknown blocker.
  • unknownIds per assessment, matched by exact provenance workflow path.
  • Closed-vocabulary requiredChanges derived from the existing blocker checks.
    • Unregistered workflows get the registry-fixed ci-invocation classifier and the plan-request, plan and gate jobs, referenced by role through needsControlRoles.
    • The gate gets an always() condition, and each execution registration keeps its current needs and adds the direct plan dependency.
    • Applying the changes produces a topology the target registry accepts.
  • Missing and mismatched registered execution jobs are reported together.
  • API, OpenAPI and TS regenerated; browser schema checks, including rejecting an owner-selected classifier; new adoption table columns.
  • Docs §9.1, §9.2 and UWA-27..30; REQ-CI-RUNTIME-026 and REQ-CI-UI-008; operator-ui route binding; CI-020 ROADMAP row.

Expected result

Every discovered workflow shows its profile, its own unknowns and the exact consumer edits that remove each fixable blocker. For an unregistered workflow, those edits lead to a topology the registry accepts.

Non-claims

  • No omission, activation, approval or production authority.
  • No GHES profile.
  • No YAML generation, no consumer write path and no agent hook.
  • Native, browser and mutation tests were not run locally.
  • The §13 target-artifact and verifier round-trip items were not re-verified.
  • CI-020 stays open until merged exact-source qualification.

Independent review: gpt-6-astra (xhigh); findings addressed or rejected with reasons in the single commit. Provisional owner decision D4 (2026-10-11): one admitted support profile (GitHub.com); unknown → full_only.

…ions

Every adoption assessment now carries a closed supportProfileId, the
report unknowns attributed by exact provenance workflow path, and a
bounded closed-vocabulary requiredChanges list derived from the same
blocker evaluation (job id, role, exact needs, gate name/condition; no
YAML generation). An unregistered (unmodified) workflow receives the
registry-fixed ci-invocation classifier, owner-named plan-request, plan
and gate jobs referenced by role through needsControlRoles, the gate's
always() condition, and per-job execution registrations that keep the
current execution-job needs and add the direct plan dependency, so the
recommended topology admits the target registry. Missing and mismatched
registered execution jobs are now reported together.
Coordinator/provider-side blockers (support_profile_unknown,
target_semantic_projection_unavailable) carry no invented change.

Provisional owner decision D4 (2026-10-11): exactly one admitted profile,
github.com/github-actions-static/v5; any other parser version is
full_only with an explicit support_profile_unknown blocker.

The API/OpenAPI/TS projection and workbench adoption table show the
profile, exact-path unknowns and consumer changes as inert text; the
browser schema rejects mis-attributed unknowns, unexplained or missing
changes, an owner-selected classifier identity and a null profile
without its blocker.

Requirement impact: REQ-CI-RUNTIME-026 and REQ-CI-UI-008 invariants
extended; operator-ui route binding added for the new inventory
falsifier test.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant