diff --git a/skills/cuopt-developer/SKILL.md b/skills/cuopt-developer/SKILL.md index b20c2da1e7..dfbafcd2c1 100644 --- a/skills/cuopt-developer/SKILL.md +++ b/skills/cuopt-developer/SKILL.md @@ -177,7 +177,6 @@ pytest -v python/cuopt/cuopt/tests pytest -v python/cuopt_server/tests ``` - #### Download test datasets before running tests cuOpt tests depend on MPS/data files that are not checked into the repo. A @@ -191,7 +190,6 @@ Before running any C++ or Python tests, follow the dataset download and If a test fails with a missing-file error, run the matching download step from `CONTRIBUTING.md` and re-run the test. Do not report missing-dataset failures back to the user as the task outcome. - ## Python Bindings @@ -385,7 +383,6 @@ All dependencies are managed through `dependencies.yaml` — never edit `conda/e | CUDA out of memory | Reduce problem size | | Build fails with CUDA errors on older driver | Conda installs `cuda-nvcc` for the latest supported CUDA (e.g., 13.1), but your GPU driver may not support it. Check with `nvidia-smi` — the top-right shows max CUDA version. Override with: `conda install cuda-nvcc=12.9` (or whichever version your driver supports). See [CUDA compatibility matrix](https://docs.nvidia.com/deploy/cuda-compatibility/) | | Slow debug library loading | Device symbols cause delay | - | CI state doesn't persist between runs | CI containers are ephemeral. Never write persistent state to repo files from CI — use S3 (`CUOPT_S3_URI`) or artifact stores. Ask: "After this container dies, does tomorrow's run see today's data?" | | CI state transitions go unreported | When CI tracks state over time (e.g. test failures), every transition (new failure, recurring, stabilized) needs an explicit notification path. Ask: "When state X changes to Y, who learns about it and how?" | | Designing CI features without lifecycle check | Before shipping any CI feature that tracks state: (1) Where does state live between runs? (2) What writes/reads it? (3) What happens on state transitions? Verify end-to-end, not just the happy-path logic. | @@ -394,7 +391,6 @@ All dependencies are managed through `dependencies.yaml` — never edit `conda/e | Same logic duplicated across files | When the same block (>10 lines) appears in 2+ places — any language, any context — extract a shared helper immediately. Don't duplicate first and refactor later. This applies to shell scripts, Python modules, C/C++ code equally. | | Feature not extensible for new variants | After implementing, ask: "If someone adds a new variant (test type, matrix entry, endpoint, etc.), what do they change?" If the answer is more than a one-line addition, the design needs a shared helper or auto-discovery. Avoid hardcoded lists of known variants. | | Reports generated without actionable detail | Reports and notifications must include enough context to act without digging: error messages, execution context (matrix, commit), history (new vs recurring), and links or attachments for full details. Provide downloadable artifacts when possible. | - ## CI Gotchas diff --git a/skills/cuopt-installation-developer/SKILL.md b/skills/cuopt-installation-developer/SKILL.md index 0d340583bd..61013c99e4 100644 --- a/skills/cuopt-installation-developer/SKILL.md +++ b/skills/cuopt-installation-developer/SKILL.md @@ -21,7 +21,6 @@ Ask these if not already clear: 2. **Goal** — Contributing upstream, or local fork/modification? 3. **Component** — C++/CUDA core, Python bindings, server, docs, or CI? - ## Validate CUDA/driver compatibility before building Before creating the conda env or running `./build.sh`, check that the conda env's @@ -50,7 +49,6 @@ Steps: Do this check before starting the build — a full build takes tens of minutes and the failure only appears when tests run. - ## Typical setup (conceptual) diff --git a/skills/cuopt-routing-api-python/SKILL.md b/skills/cuopt-routing-api-python/SKILL.md index e3b4699229..728cb628b8 100644 --- a/skills/cuopt-routing-api-python/SKILL.md +++ b/skills/cuopt-routing-api-python/SKILL.md @@ -83,9 +83,7 @@ ss.set_error_logging_mode(True) | Infeasible orders | Increase fleet or capacity | | Status != 0 with time windows | Add `add_transit_time_matrix()` | | Wrong cost | Check cost_matrix is symmetric | - | `compute_waypoint_sequence` alters route_df | It replaces the `location` column with waypoint ids in place — pass `route_df.copy()` if you still need cost-matrix indices (e.g. when iterating per truck) | - ## Debugging diff --git a/skills/cuopt-user-rules/SKILL.md b/skills/cuopt-user-rules/SKILL.md index cb3f71f65f..735f6955e6 100644 --- a/skills/cuopt-user-rules/SKILL.md +++ b/skills/cuopt-user-rules/SKILL.md @@ -114,9 +114,7 @@ Do not bury the objective value only in the middle of a paragraph; it must appea Provide diagnostic code snippets when helpful. ### Post-correction check (mandatory) - If the result required a correction, retry, or workaround to reach this point, you MUST evaluate the skill-evolution workflow (`skills/skill-evolution/SKILL.md`) before moving on. Do not skip this step. - --- diff --git a/skills/lp-milp-formulation/SKILL.md b/skills/lp-milp-formulation/SKILL.md index e429282033..4b30dd0793 100644 --- a/skills/lp-milp-formulation/SKILL.md +++ b/skills/lp-milp-formulation/SKILL.md @@ -129,7 +129,6 @@ Result: Parameters = 3 factories, 500 units target. Constraints = produce exactl --- - ## Piecewise-linear objectives with integer production When modeling **concave piecewise-linear** profit/cost functions (e.g. decreasing marginal profit for bulk sales), the standard approach uses continuous segment variables with upper bounds equal to each segment's width. For a maximization with concave profit, the solver fills higher-profit segments first naturally. @@ -146,9 +145,7 @@ Link: x_total = s1 + s2 + … Resource constraints use x_total. Objective uses segment variables × segment profit rates. ``` - - ## Cutting stock / trim loss problems In cutting stock problems, **waste area** includes both **trim loss** (unused width within each cutting pattern) and **over-production** (excess strips produced beyond demand). Minimizing only trim loss (waste width × length per pattern) ignores over-production and yields an incorrect objective. @@ -172,9 +169,7 @@ where `required_useful_area = sum_i (order_width_i × order_length_i)`. ### Gotcha Using `sum_j (waste_width_j × x_j)` as the objective only captures trim loss — the unused strip within each pattern. It does **not** penalize over-production of an order. The solver will over-produce narrow orders to fill patterns efficiently, but that excess material is still waste. Always use total material area as the objective. - ## Goal programming (preemptive / lexicographic) - Goal programming optimizes multiple objectives in priority order. Implement it as **sequential solves** — one per priority level. @@ -192,7 +187,6 @@ Deviation variables (d⁻, d⁺) and slack/idle-time variables are always **cont --- - ## Multi-period inventory / purchasing models In problems with buying, selling, and warehouse capacity over multiple periods, decide which capacity constraints to include based on the problem's timing assumptions. @@ -212,9 +206,7 @@ For each period *t* with inventory balance `stock[t] = stock[t-1] + buy[t] - sel **Key interaction with the sell constraint:** If the model already has `sell[t] <= stock[t-1]` (grain bought this period cannot be sold this period), the model is bounded even without the after-purchase constraint. The sell constraint prevents unbounded buy-sell cycling. The after-purchase constraint is then an additional physical restriction, not a mathematical necessity. **Default:** If the problem does not specify timing within a period, use **only** end-of-period capacity (`stock[t] <= capacity`). Add the after-purchase constraint only if the problem explicitly requires it. - - ## Blending with shared mixing / intermediate processing In some blending problems, a subset of raw materials must be **mixed together first** (e.g., in a mixing tank) before being allocated to different products. The resulting intermediate has a **uniform composition** — you cannot independently assign different raw materials to different products. @@ -237,4 +229,3 @@ Before formulating, check whether using the intermediate in each product is prof - Compare the **minimum cost per ton** of the intermediate (using cheapest feasible raw material mix) against each product's **selling price**. - If `cost_intermediate > sell_price[j]` for some product `j`, the intermediate should not be allocated to product `j`. Raw material C (or other direct inputs) alone may also be unprofitable if `cost_C > sell_price[j]`. - This analysis often eliminates the need for a bilinear split entirely. -