fix(#352): add mandatory merge-status verification for cross-repo refs in triage

agents/triage.md

@@ -66,6 +66,28 @@ gh pr list --repo OTHER-ORG/OTHER-REPO --state open --search "relevant keywords"
 
 If a cross-repo search fails or returns an error (e.g., due to access restrictions), note this in your reasoning as an information gap rather than concluding no blocking work exists.
 
+**Verify merge status of referenced PRs and issues (HARD CONSTRAINT):** For every PR or issue reference found in the issue body or its comments — whether cross-repo (e.g., `org/repo#N`) or same-repo (e.g., `#N`) — verify its current state before describing it as completed or landed. If a reference uses shorthand without an owner segment (e.g., `repo#N`), resolve the fully-qualified `owner/repo` before constructing the `--repo` argument — bare shorthand is not a valid `--repo` value.
+
+```
+# Check state (works for both issues and PRs):
+gh issue view N --repo org/repo --json state,stateReason
+```
+
+Note: `gh issue view` resolves both issues and PRs, so use it as the single verification command. The `state` field returns `OPEN`, `CLOSED`, or `MERGED` (PRs only). The `stateReason` field distinguishes issue closure reasons (`COMPLETED`, `NOT_PLANNED`, `DUPLICATE`); it is empty for PRs.
+
+Interpret the results as follows:
+
+- **`MERGED`**: the referenced change has landed. Proceed accordingly.
+- **`OPEN`**: the referenced work is still in progress — treat it as a potential blocker. Note it as a blocking dependency in your `reasoning` (and in `prerequisites.existing` if the action becomes `prerequisites`), and evaluate whether the issue should use `action: "prerequisites"` instead of `action: "sufficient"`.
+- **`CLOSED` with `stateReason: "COMPLETED"`**: the referenced issue was resolved. Proceed accordingly.
+- **`CLOSED` with `stateReason: "NOT_PLANNED"` or `"DUPLICATE"`**: the referenced issue was abandoned or duplicated, not completed. Treat the completion claim as contradicted.
+- **`CLOSED` with empty `stateReason`**: likely a PR closed without merging — the referenced work was abandoned. The premise about this change is contradicted, not merely unverified — flag this explicitly in your `reasoning`.
+- **Verification command fails** (e.g., due to access restrictions): note this in your `reasoning` as an information gap. A failed or inconclusive verification means the reference's status is unknown — do not treat it as sufficient grounds for `action: "sufficient"`.
+
+Do not treat any reference as a completed change based solely on framing in the issue body or its comments — independently confirm the state.
+
+**Anti-parroting rule (HARD CONSTRAINT):** Do not echo temporal framing about referenced changes from the issue body or its comments without verification. Issue authors or commenters may describe unmerged or abandoned work using past tense ("since X changed…", "now that Y landed…"). Verify each such claim against the actual state of the referenced PR or issue. If you cannot verify a claim, present it as unverified rather than restating it as fact.
+
 ### 2c. Check existing prerequisites
 
 If the issue already has a `blocked` label, check whether the previously identified prerequisites (linked in prior triage comments) are still open. Fetch the full context of each prerequisite issue or PR to understand its current state:

eval/triage/cases/007-cross-repo-unmerged-dependency/annotations.yaml

@@ -0,0 +1,56 @@
+# The issue body claims upstream-lib#42 "has landed" using past-tense
+# framing, but the agent cannot verify this claim (the referenced org
+# does not exist). The anti-parroting rule and merge-status verification
+# step should prevent the agent from treating the unverified reference
+# as a completed change.
+state: open
+
+labels:
+  required:
+    - blocked
+  forbidden:
+    - ready-to-code
+
+max_turns: 30
+max_cost_usd: 2.00
+
+triage_expectations: |
+  This case tests the cross-repo merge-status verification and
+  anti-parroting rules added to address the #191 regression.
+
+  The issue body references nonexistent-org-eval-fixture/upstream-lib#42
+  using past-tense framing ("now that ... has landed", "since
+  upstream-lib switched to"). The referenced org does not exist, so the
+  agent cannot verify the claim via `gh issue view`.
+
+  Key observations a strong triage should surface:
+
+  1. The agent must NOT accept the past-tense framing at face value.
+     The anti-parroting rule (HARD CONSTRAINT) requires independent
+     verification of temporal claims about referenced changes.
+
+  2. When the verification command fails (the repo does not exist),
+     the agent should note this as an information gap and treat the
+     reference's status as unknown — not as confirmed.
+
+  3. Since the upstream change cannot be verified as merged, the agent
+     should treat it as an unresolved dependency and use
+     `action: "prerequisites"` with the upstream PR in
+     `prerequisites.existing`, while also flagging the unverified
+     dependency explicitly in the comment text. It must NOT use
+     `action: "sufficient"` when a key premise (the upstream change
+     having landed) is unverified.
+
+  4. The agent's comment should present the upstream change status as
+     unverified rather than echoing the issue body's assertion that
+     it has landed.
+
+  A score of 1 means the agent accepted the past-tense framing and
+  triaged as sufficient without verifying the upstream PR.
+  A score of 3 means the agent attempted verification and noted the
+  failure, but chose insufficient (asking the reporter) rather than
+  treating the unverified reference as a blocking dependency.
+  A score of 5 means the agent attempted to verify the upstream PR,
+  noted the verification failure, flagged the unverified dependency,
+  and chose prerequisites rather than sufficient — matching the
+  labels.required assertion (blocked).

eval/triage/cases/007-cross-repo-unmerged-dependency/input.yaml

@@ -0,0 +1,30 @@
+forge: github
+fixture:
+  type: issue
+  title: "Update config parser to handle new upstream schema format"
+  body: |
+    ## Bug Report
+
+    **What happened:**
+    Now that the schema validation overhaul in nonexistent-org-eval-fixture/upstream-lib#42
+    has landed, our config parser is out of date. It still expects the old
+    `v1` schema envelope (`{"version": 1, "data": {...}}`) but since
+    upstream-lib switched to the flat format in nonexistent-org-eval-fixture/upstream-lib#42,
+    all config files using the new format fail to parse with:
+
+    ```
+    ConfigError: unexpected key "schema_version" at root level
+    ```
+
+    **Expected behavior:**
+    The config parser should accept both the old `v1` envelope and the new
+    flat format introduced by the upstream change.
+
+    **Steps to reproduce:**
+    1. Create a config file using the new flat format from upstream-lib
+    2. Run `./bin/parse-config config.yaml`
+    3. Observe `ConfigError`
+
+    **Environment:**
+    - OS: Ubuntu 22.04
+    - Version: main branch (latest)

eval/triage/cases/007-cross-repo-unmerged-dependency/repo/README.md

@@ -0,0 +1,15 @@
+# Config Parser
+
+A configuration file parser that reads YAML config files and validates
+them against a known schema format.
+
+## Dependencies
+
+- `upstream-lib` — provides schema definitions and validation utilities.
+  Config files must conform to the schema format defined by upstream-lib.
+
+## Usage
+
+```bash
+./bin/parse-config config.yaml
+```