Improve review pipeline: whitelist scoping, CI paper check, complexity reporting

- Fix whitelist false positives: use origin/main (not local main) as
  merge-base in review-implementation, so after merge-with-main the diff
  only shows PR files
- Add make paper to CI (install typst, run after tests) to catch paper
  regressions on main
- Fix pre-existing paper error: SequencingToMinimizeWeightedCompletionTime
  used removed x.optimal API
- Extract and report complexity strings in model completeness check so
  reviewers can compare against issue specification
- Document canonical_model_example_specs() requirement in add-model skill

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: GiggleLiu

.claude/skills/add-model/SKILL.md

@@ -186,9 +186,11 @@ Update `problemreductions-cli/src/commands/create.rs` so `pred create <ProblemNa
 
 Add a builder function in `src/example_db/model_builders.rs` that constructs a small, canonical instance for this model. Register it in `build_model_examples()`.
 
+Also add `canonical_model_example_specs()` **in the model file itself** (gated by `#[cfg(feature = "example-db")]`), and register it in the category `mod.rs` example chain (e.g., `specs.extend(<module>::canonical_model_example_specs());`). See any existing model in `src/models/graph/` for the pattern.
+
 This example is now the canonical source for:
 - `pred create --example <PROBLEM_SPEC>`
-- paper/example exports
+- paper/example exports via `load-model-example()` in `reductions.typ`
 - example-db invariants tested in `src/unit_tests/example_db.rs`
 
 ## Step 5: Write unit tests

.claude/skills/fix-issue/SKILL.md

@@ -10,9 +10,12 @@ Fix errors and warnings from a `check-issue` report. Auto-fixes mechanical issue
 ## Invocation
 
 ```
-/fix-issue <model|rule>
+/fix-issue <model|rule|issue-number>
 ```
 
+- `/fix-issue model` or `/fix-issue rule` — pick next from Backlog
+- `/fix-issue 207` — fix a specific issue by number (skip Step 1a/1b, go directly to 1c)
+
 ## Constants
 
 GitHub Project board IDs:
@@ -59,7 +62,10 @@ digraph fix_issue {
 
 ## Step 1: Pick Next Issue from Backlog
 
-The argument is `model` or `rule` — determines which issue type (`[Model]` or `[Rule]`) to process.
+The argument is `model`, `rule`, or a specific issue number.
+
+- If a **number** is given, skip to Step 1c with that issue.
+- If `model` or `rule`, pick from the Backlog as below.
 
 ### 1a: Fetch candidate list from project board
 
@@ -83,6 +89,8 @@ Returns all Backlog issues of the requested type, sorted by `Good` label first t
 
 Pick the first item from the list. If the list is empty, STOP with message: "No `[Model]`/`[Rule]` issues in Backlog."
 
+If the top issue already has the `Good` label and its check report has **0 failures and 0 warnings**, skip to Step 8 (just move it to Ready — no edits needed). If it has warnings, proceed normally.
+
 ### 1c: Fetch the chosen issue
 
 ```bash
@@ -136,8 +144,8 @@ Tag each issue as:
 | Missing type dependencies | Architectural decision about codebase |
 | Incorrect mathematical claims | Domain expertise needed |
 | Incomplete reduction algorithm | Core technical content |
-| Incomplete or trivial example | Needs meaningful design, provide 3 options for the human to choose from |
-| Decision vs optimization framing | Check associated `[Rule]` issues first — if a rule targets the decision version, implement that; if it targets optimization, implement that; if both exist, split into two separate model issues. Problem modeling choice |
+| Incomplete or trivial example | Present **3 concrete example options** with pros/cons (use `AskUserQuestion` with previews showing vertex/edge counts, optimal values, and suboptimal cases). Prefer examples that match the model issue's example when a companion model exists. |
+| Decision vs optimization framing | **Default to optimization** unless evidence points otherwise. The project prefers `OptimizationProblem` (like MIS, SpinGlass, TSP) because optimization subsumes decision. Check associated `[Rule]` issues (`gh issue list --search "<ProblemName> in:title label:rule"`) to see how rules use the model — if rules only need the decision version (e.g., reducing to SAT with a bound), optimization still works since you can extract the bound from the optimal value. Only use `SatisfactionProblem` for inherently decision/feasibility problems (SAT, KColoring) where there is no natural optimization objective. If switching to optimization, add the appropriate `Minimum`/`Maximum` prefix per codebase conventions. |
 | Ambiguous overhead expressions | Requires understanding the reduction |
 
 ---
@@ -232,14 +240,28 @@ Apply the requested changes to the draft issue body, re-check locally (Step 6),
 
 Only reached when the human approves. Now push everything to GitHub.
 
-### 8a: Edit the issue body
+### 8a: Edit the issue body and title
 
 Use the Write tool to save the updated body to `/tmp/fix_issue_body.md`, then:
 
 ```bash
 gh issue edit <NUMBER> --body-file /tmp/fix_issue_body.md
 ```
 
+If the problem name was changed (e.g., renamed to add `Minimum`/`Maximum` prefix), also update the issue **title**:
+
+```bash
+gh issue edit <NUMBER> --title "[Model] NewProblemName"
+```
+
+Then find and update **all related issues** that reference the old name in their title:
+
+```bash
+gh issue list --search "OldName in:title" --state open --json number,title
+# For each related issue, update the title:
+gh issue edit <RELATED_NUMBER> --title "<updated title>"
+```
+
 ### 8b: Comment on the issue with a changelog
 
 Post a comment summarizing what was changed, so reviewers can see the diff at a glance:
@@ -295,3 +317,4 @@ Done! Issue #<NUMBER>:
 | Closing the issue | Never close. Labels and board status only |
 | Force-pushing or modifying git | This skill only edits GitHub issues via `gh`. No git operations |
 | Inventing `pipeline_board.py` subcommands | Only `next`, `claim-next`, `ack`, `list`, `move`, `backlog` exist |
+| Forgetting to update the issue title | If the problem name changed, update the title with `gh issue edit <N> --title "..."` and find all related issues referencing the old name |

.github/workflows/ci.yml

@@ -42,6 +42,12 @@ jobs:
       - name: Run doc tests
         run: cargo test --doc --features ilp-highs --verbose
 
+      - name: Install typst
+        uses: typst-community/setup-typst@v4
+
+      - name: Build paper
+        run: make paper
+
   # Code coverage
   coverage:
     name: Code Coverage

docs/paper/reductions.typ

@@ -3723,7 +3723,7 @@ A classical NP-complete problem from Garey and Johnson @garey1979[Ch.~3, p.~76],
   let weights = x.instance.weights
   let precs = x.instance.precedences
   let ntasks = lengths.len()
-  let sol = x.optimal.at(0)
+  let sol = (config: x.optimal_config, metric: x.optimal_value)
   let opt = sol.metric.Valid
   let lehmer = sol.config
   let schedule = {

scripts/pipeline_checks.py

@@ -183,6 +183,15 @@ def check_entry(
     }
 
 
+def _extract_complexity_strings(model_text: str) -> str:
+    """Extract complexity strings from declare_variants! for issue comparison."""
+    matches = re.findall(r'=>\s*"([^"]+)"', model_text)
+    if matches:
+        unique = list(dict.fromkeys(matches))
+        return "complexity: " + "; ".join(unique)
+    return "complexity: not found"
+
+
 def model_completeness(repo_root: Path, name: str) -> dict:
     file_stem = camel_to_snake(name)
     model_file = find_model_file(repo_root, file_stem)
@@ -206,7 +215,8 @@ def model_completeness(repo_root: Path, name: str) -> dict:
             else check_entry(status="fail", detail="missing ProblemSchemaEntry for model")
         ),
         "declare_variants": (
-            check_entry(status="pass", path=str(model_file.relative_to(repo_root)))
+            check_entry(status="pass", path=str(model_file.relative_to(repo_root)),
+                        detail=_extract_complexity_strings(model_text))
             if model_file is not None
             and "crate::declare_variants!" in model_text
             and re.search(r"\b(?:default\s+)?(?:opt|sat)\b", model_text)

scripts/pipeline_skill_context.py

@@ -812,7 +812,7 @@ def build_review_implementation_context(
     review_context_builder: Callable[..., dict] | None = None,
 ) -> dict:
     merge_base_getter = merge_base_getter or (
-        lambda repo_root: git_text_in(repo_root, "merge-base", "main", "HEAD").strip()
+        lambda repo_root: git_text_in(repo_root, "merge-base", "origin/main", "HEAD").strip()
     )
     head_sha_getter = head_sha_getter or (
         lambda repo_root: git_text_in(repo_root, "rev-parse", "HEAD").strip()