@bridge_gpt/mcp-server 0.2.52 → 0.2.54

package/pipelines/review-ticket.json

@@ -1,7 +1,13 @@
 {
   "name": "review-ticket",
-  "description": "Review a ticket, evaluate suggestions for accuracy, and produce a combined review-and-resolution document with decision trees. A single request_ticket_review step runs the backend's resolved difficulty-adaptive review policy, which internally runs any second-opinion rounds server-side. Pass --rounds=1|2 to forward an explicit round count that forces the review shape (1 = single pass, 2 = full second-opinion review); omit it to let the backend policy executor decide adaptively. The round count is injected into the request_ticket_review step as a real integer by get_pipeline_recipe, not substituted as a recipe variable.",
-  "variables": ["ticket_key", "docs_dir", "base_branch", "base_sha", "no_refresh_base"],
+  "description": "Review a ticket, evaluate suggestions for accuracy, and produce a combined review-and-resolution document with decision trees. A single request_ticket_review step runs the backend's resolved difficulty-adaptive review policy, which internally runs any second-opinion rounds server-side. Pass --rounds=1|2 to forward an explicit round count that forces the review shape (1 = single pass, 2 = full second-opinion review); omit it to let the backend policy executor decide adaptively. The round count is injected into the request_ticket_review step as a real integer by get_pipeline_recipe, not substituted as a recipe variable. BAPI-1121: this recipe has SEVEN steps, not nine — the former standalone retrieve-clarifying-questions and retrieve-ticket-critique MCP calls were removed because generation-aware persistence is performed by the shared artifact gate (ticket-review-artifact-gate.ts), which this recipe reaches through wait_for_ticket_review (see the wait step's instruction). BAPI-1129: that gate is the sole persistence implementation for the two review documents, shared by both calling conventions — blocking request_ticket_review(wait_for_result: true) reaches the same gate — so no step here may retrieve or save a review document on its own.",
+  "variables": [
+    "ticket_key",
+    "docs_dir",
+    "base_branch",
+    "base_sha",
+    "no_refresh_base"
+  ],
   "steps": [
     {
       "type": "mcp_call",
@@ -14,13 +20,20 @@
       "tool": "request_ticket_review",
       "params": {
         "ticket_number": "{ticket_key}",
-        "wait_for_result": true,
+        "wait_for_result": false,
         "save_locally": true,
         "provider": "{provider}"
       },
-      "description": "Generate combined clarify+critique review. The backend runs the resolved difficulty-adaptive policy (including any second-opinion rounds) server-side; an explicit rounds value (1|2) forces the shape.",
+      "description": "Submit the combined clarify+critique review and RETURN IMMEDIATELY. The backend runs the resolved difficulty-adaptive policy (including any second-opinion rounds) server-side; an explicit rounds value (1|2) forces the shape. BAPI-1104: this step no longer blocks. Blocking here bound the whole review to the 900-second MCP client deadline, and a review that outran it killed the worker mid-wait \u2014 it exited without .conductor/result.json, produced MissingVerdictArtifact, and was requeued, spending a full attempt on work that had already been done. The wait moved to the following step, which is resumable.",
       "on_error": "warn_and_continue"
     },
+    {
+      "type": "agent_task",
+      "id": "wait-for-ticket-review",
+      "instruction": "FIRST, check whether a review was actually submitted. The previous step runs with `on_error: warn_and_continue`, so a rejected submission (a 402, 403 or 500 from the generate endpoint, or a dropped connection) lets the pipeline continue into this step. If that step returned an error message rather than its submission confirmation or a `recovery_get` envelope, do NOT wait: nothing is running, and `wait_for_ticket_review` cannot tell \"never submitted\" from \"still running\" \u2014 it would read `pending` in every window until the caller's own timeout. Treat a failed submission as a terminal failure, report the error the previous step gave, and take the verdict contract's `revise` path.\n\nOtherwise, wait for the review submitted by the previous step to finish, using repeated BOUNDED windows.\n\nCall `wait_for_ticket_review` with `ticket_number` set to the ticket key. Each call occupies at most 240 seconds and returns a JSON body with a `state` field:\n\n- `state: \"pending\"` \u2014 NORMAL and expected. The review is still running. Call the tool again immediately. Do NOT sleep, do NOT poll in a shell loop, and do NOT re-run `request_ticket_review`: re-submitting starts a second billable multi-model review and abandons the one already in flight.\n- `state: \"ready\"` \u2014 the review is over. BAPI-1121: a ready result has ALREADY persisted exactly the accepted documents and reconciled the canonical source files \u2014 it writes every leg in `saved_legs` to its canonical path and removes the stale canonical file for every leg in `withheld_legs`. Do NOT call `get_clarifying_questions` or `get_ticket_critique` after a ready result; those retrieval calls were removed from this recipe because reading them again could reintroduce exactly the stale content the wait just withheld. Treat `saved_legs` as the authoritative source set for the next steps, not file presence.\n  - `freshness_basis: \"generation\"` is the normal case: `advanced_legs`/`saved_legs` are current-review evidence, proven newer than the submission. Any leg in `withheld_legs` was delivered but NOT proven current \u2014 surface its `reason` (`generation_not_advanced` or `identity_unreadable`) as a visible warning; do not describe the result as an ordinary cost-saved one-leg review when a withholding occurred. A leg in `absent_legs` with `reason: \"not_delivered\"` is an ordinary policy omission (e.g. an Easy-ticket clarify-only review) unless its status also flags it as policy-expected, in which case call that out too.\n  - `freshness_basis: \"terminality_only\"` means no submission baseline was available (e.g. a resumed session) \u2014 `advanced_legs` is empty by construction and `saved_legs` was accepted on terminal delivery alone. Surface this prominently as a DEGRADED-freshness warning: the saved artifact(s) may be indistinguishable from a prior attachment, and the downstream identity-footer agreement check is the remaining backstop. Retain this warning when reporting to the next steps rather than treating a `terminality_only` ready result as equivalent to a `generation`-backed one.\n  - If the result instead carries `state: \"error\"` alongside a persistence failure (an `ARTIFACT_PERSISTENCE_FAILED` `error`/`status`/`message` envelope), HALT rather than proceeding with whatever files happen to exist on disk \u2014 report the failure; the accepted legs already on disk before the failure are named in the envelope and are not lost, but nothing new was persisted for this window.\n- `state: \"error\"` \u2014 terminal. Report the `reason` and stop; the review will not complete on its own. `UPSTREAM_TERMINAL` means the review failed or expired server-side \u2014 take the verdict contract's `revise` path; do NOT open another wait window and do NOT re-run `request_ticket_review`. `INVALID_RESPONSE` means the delivered document could not be read.\n\nKeep looping on `pending` for as long as this session's own budget allows. There is no iteration cap here: the bound is the caller's \u2014 for the conductor's spec-review worker that is the existing 120-minute job timeout, which produces the ordinary liveness outcome if the review never lands. Never fabricate a verdict or a review result from a pending state.",
+      "description": "Wait for the submitted review in repeated bounded windows; a ready result has already persisted the accepted documents and reconciled the canonical files (BAPI-1121). Resumable: a pending result is a normal observation, not a failure.",
+      "on_error": "halt"
+    },
     {
       "type": "mcp_call",
       "id": "materialize-fresh-base",