Promote Hosted Operation Canary candidate spec graph#683
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3c72fad03b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - CANDIDATE-CANDIDATE-SPEC-ESCALATE-FAILED-CANARY-CHECKS-TO-THE-SERVICE-OWNER | ||
| relates_to: [] | ||
| inputs: | ||
| - runs/hosted-operation-canary/repaired_candidate_repair_loop_report.json#revised_candidate_graph_preview |
There was a problem hiding this comment.
These hosted canary YAML previews all point at runs/hosted-operation-canary/repaired_candidate_repair_loop_report.json#revised_candidate_graph_preview, but the commit tracks only the YAML files and no corresponding repaired candidate graph, repair-loop, materialization, promotion-gate, or handoff report under this run directory (checked git ls-files runs/hosted-operation-canary). In this state reviewers and downstream promotion tooling cannot verify the candidate graph/readiness chain that produced the promoted specs, so the added artifacts are present but not reviewable/ready; include the matching repaired handoff artifacts or keep these previews local until that chain is committed.
Useful? React with 👍 / 👎.
| @@ -0,0 +1,106 @@ | |||
| id: CANDIDATE-CANDIDATE-SPEC-PRODUCT-BOUNDARY | |||
There was a problem hiding this comment.
This hosted canary preview reuses the generic CANDIDATE-CANDIDATE-SPEC-PRODUCT-BOUNDARY id that is already tracked for the Team Decision Log preview at runs/repaired_materialized_candidate_specs/CANDIDATE-CANDIDATE-SPEC-PRODUCT-BOUNDARY.yaml; since the publish bundle walks and copies all non-local-only files under runs/, both YAML files can be exposed to downstream graph/promotion consumers with the same spec id but different product semantics. Give hosted-operation-canary materialized specs candidate-scoped ids before publishing them so consumers do not collapse or reject distinct product boundaries as duplicates.
Useful? React with 👍 / 👎.
| inputs: | ||
| - runs/hosted-operation-canary/repaired_candidate_repair_loop_report.json#revised_candidate_graph_preview | ||
| outputs: | ||
| - runs/hosted-operation-canary/repaired_materialized_candidate_specs/CANDIDATE-CANDIDATE-SPEC-PRODUCT-BOUNDARY.yaml |
There was a problem hiding this comment.
The new hosted canary preview paths are not wired into any approval surface: the only tracked runs/candidate_approval_decision.json still identifies team-decision-log and its promotion_request.paths point at runs/repaired_materialized_candidate_specs/..., while git ls-files runs/hosted-operation-canary/*approval* returns nothing. As a result, an operator following the approved promotion handoff will promote the older Team Decision Log files and leave these hosted-operation-canary specs as unapproved stray previews; add a hosted canary approval decision/promotion request or update the intended approval artifact to reference these paths.
Useful? React with 👍 / 👎.
1 participant
Approve candidate for promotion review.