fix: address routing depth scrutiny findings (#448)

Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>

.claude-plugin/marketplace.json

@@ -966,7 +966,7 @@
         "./product-strategy"
       ],
       "strict": false,
-      "description": "Set product vision and strategy with a CPO methodology. Do not use this skill for unrelated requests; route to the nearest named specialist."
+      "description": "Set product vision, positioning, market strategy, and portfolio direction with a CPO methodology. Route tactical prioritization, specifications, and backlog decisions to `product-methodology`; do not use this skill for delivery-level product decisions or unrelated requests."
     },
     {
       "name": "production-excellence",

go-to-market/README.md

@@ -12,6 +12,7 @@ Your agent reasons about positioning, acquisition channels, and growth economics
 |-----------|---------|
 | `SKILL.md` | Core methodology, trigger conditions, reference index |
 | `references/` | Deep-dive frameworks plus `decision-workflow.md` for launch decisions and routing |
+| `evals/evals.json` | Output-quality cases for positioning, acquisition, growth, and launch decisions |
 
 ## Triggers
 

legal-strategy/README.md

@@ -12,6 +12,7 @@ Your agent applies structured legal analysis — GDPR articles, liability cap ti
 |-----------|---------|
 | `SKILL.md` | Core methodology, trigger conditions, reference index |
 | `references/` | Regulatory, IP, contract, privacy, and counsel-escalation decision references |
+| `evals/evals.json` | Output-quality cases for bounded legal-risk analysis and counsel escalation |
 
 ## Triggers
 

llms.txt

@@ -108,7 +108,7 @@
 - [product-operations-and-governance](product-operations-and-governance/SKILL.md): Define and run product governance — recurring decision rights, intake, portfolio cadences, evidence standards, and cross-functional operating contracts. Covers six review cadences (intake, portfolio, roadmap, experiment, launch, lifecycle) with named accountable owners, minimum evidence standards per decision type, and escalation paths. Supports lightweight and high-assurance operating modes with configurable governance patterns. Use when designing a product governance model, resolving contested decisions, establishing evidence standards, recording exceptions and escalations, or building cross-functional operating contracts. Do NOT use for executive governance (capital allocation, org structure — route to chief-of-staff-methodology or strategy-frameworks), for technical delivery gates (CI/CD, release approval — route to release-engineering or spec-driven-development), or to impose a universal org chart.
 - [product-roadmapping-and-portfolio](product-roadmapping-and-portfolio/SKILL.md): Build and maintain outcome-based product roadmaps and portfolio views that sequence strategic bets by evidence, not dates. Covers Now/Next/Later views, strategic-bet management, capacity allocation, dependency and confidence mapping, scenario planning, continue/pause/kill/revisit criteria, stakeholder narratives, and roadmap review cadences. Use when building or reviewing a product roadmap, managing a portfolio of bets, or communicating strategic sequencing to stakeholders. Do NOT use for tactical prioritization mechanics (RICE, MoSCoW, Kano, OST — route to product-methodology or product-strategy), for project scheduling or Gantt charts, or for delivery-flow management (route to kanban-guru).
 - [product-shaping](product-shaping/SKILL.md): Use this skill to shape product or engineering work before committing time to it: set appetites instead of estimates, narrow raw ideas into bounded problems, sketch solutions at the right level of abstraction, de-risk rabbit holes, write pitches, bet with capped downside (circuit breaker), and govern builds with discovered scopes and scope hammering. Adapted from Basecamp's Shape Up and extended for human+AI-agent teams. Use when a raw idea, feature request, or "redesign X" grab-bag needs to become a bounded project before anyone builds; when planning how much work an idea is worth; or when delegated agent builds need budgets, kill criteria, and non-convergence rules. Do not use for discovering whether a problem is real (use product-discovery), for portfolio-level sequencing across quarters (product-roadmapping-and-portfolio), for formal specification after the bet is placed (spec-driven-development), or for task-level prioritization frameworks like RICE (product-methodology).
-- [product-strategy](product-strategy/SKILL.md): Set product vision and strategy with a CPO methodology. Do not use this skill for unrelated requests; route to the nearest named specialist.
+- [product-strategy](product-strategy/SKILL.md): Set product vision, positioning, market strategy, and portfolio direction with a CPO methodology. Route tactical prioritization, specifications, and backlog decisions to `product-methodology`; do not use this skill for delivery-level product decisions or unrelated requests.
 - [production-excellence](production-excellence/SKILL.md): Build cross-domain production evidence from readiness, migration, recovery, capacity/cost, and incident learning into launch or operational decisions. Do not use this skill for a single specialist's risk packet and launch gate; use `production-readiness` for that readiness review.
 - [production-readiness](production-readiness/SKILL.md): Define risk-scaled evidence packets and go/no-go/defer/exception launch gates with accountable owners. Do not use this skill for cross-domain production composition; use `production-excellence` for assembling migration, recovery, capacity, and incident evidence.
 - [programming-principles](programming-principles/SKILL.md): Apply distilled coding principles from 14 classic software books to code review, refactoring, design, and implementation decisions. Do not use for language- or framework-specific tutorials, tool manuals, or tasks already governed by a project's established conventions.

operational-design/README.md

@@ -12,6 +12,7 @@ Your agent applies COO-level frameworks — value stream mapping, scaling stages
 |-----------|---------|
 | `SKILL.md` | Core methodology, trigger conditions, reference index |
 | `references/` | Process, metrics, compliance, vendor, scaling, and bounded decision workflows |
+| `evals/evals.json` | Output-quality cases for process, metrics, compliance, and vendor decisions |
 
 ## Triggers
 

org-design/README.md

@@ -12,6 +12,7 @@ Your agent reasons about team structure, compensation, and culture with real fra
 |-----------|---------|
 | `SKILL.md` | Core methodology, trigger conditions, reference index |
 | `references/` | Topology, talent, compensation, culture, and decision-workflow references |
+| `evals/evals.json` | Output-quality cases for topology, talent, compensation, and culture decisions |
 
 ## Triggers
 

product-methodology/SKILL.md

@@ -70,6 +70,10 @@ Load this skill when:
 4. Write specs that define the problem, success metrics, scope boundaries, open questions, and edge cases.
 5. Communicate decisions in the format each audience needs — recommendation-first for executives, context-first for engineers, listening-first for customers.
 
+## Routing Boundary
+
+Use `product-strategy` for CPO-level vision, positioning, market strategy, and portfolio direction. Route tactical prioritization, specifications, decision logs, and backlog sequencing back here once strategic direction and validated evidence are available; do not make portfolio strategy decisions in this skill.
+
 ## Portability
 
 This skill is intentionally host-neutral. It requires no profile system, output format, scripts, or external services. Load references directly by path — use the host agent's normal file-loading mechanism.

product-strategy/SKILL.md

@@ -1,8 +1,10 @@
 ---
 name: product-strategy
 description: >-
-  Set product vision and strategy with a CPO methodology. Do not use this skill for
+  Set product vision, positioning, market strategy, and portfolio direction with a
-  unrelated requests; route to the nearest named specialist.
+  CPO methodology. Route tactical prioritization, specifications, and backlog
+  decisions to `product-methodology`; do not use this skill for delivery-level
+  product decisions or unrelated requests.
 license: MIT
 metadata:
   tags: product-strategy, cpo, product-management, competitive-analysis, market-sizing,
@@ -51,6 +53,6 @@ The profile using this skill produces artifact pyramids. The response to any cal
 ## Related Skills
 
 - `artifact-pyramids` — output contract
-- `product-methodology` — tactical product management (RICE, MoSCoW, customer interviews)
+- `product-methodology` — tactical product management: route validated evidence here for prioritization, specifications, decision logs, and backlog decisions; this skill does not own those delivery-level choices.
 - `go-to-market` — CMO methodology (positioning, acquisition, brand, growth modeling)
 - `implementation-planning` — work breakdown and dependency ordering

telemetry/README.md

@@ -15,7 +15,7 @@ The references are distilled from the official Prometheus, OpenTelemetry Collect
 | Directory | Purpose |
 |---|---|
 | `SKILL.md` | Agent-facing operating loop, mutation gates, and verification boundaries |
-| `references/` | Six dated references: source index, Prometheus operations, OpenTelemetry Collector, Loki operations, bounded PromQL/LogQL query workflows, stack integration and retention |
+| `references/` | Six focused references: source index, Prometheus operations, OpenTelemetry Collector, Loki operations, bounded PromQL/LogQL query workflows, stack integration and retention |
 | `scripts/telemetry-check` | Read-only rule sanity + scrape-target reachability checker: stdlib-only Python, `--json`, `--rules`/`--scrape`/`--targets`, `--help` with no server |
 | `fixtures/` | Valid `prometheus-rules.yml` and `scrape-config.yml` used by the tests and as starting points |
 | `tests/` | Deterministic tests against the fixture configs, including the read-only contract |
@@ -37,7 +37,7 @@ telemetry/scripts/telemetry-check --scrape telemetry/fixtures/scrape-config.yml
 telemetry/scripts/telemetry-check --targets targets.txt --timeout 5
 ```
 
-Exit codes: 0 all checks passed, 1 issues found or a fatal error, 2 usage error. The rule checks mirror `promtool check rules` for structure (exactly one of `record`/`alert`, non-empty `expr` with balanced delimiters, valid durations, valid names and label values); use `promtool check rules` when you need full PromQL parsing.
+Exit codes: 0 all checks passed, 1 issues found or a fatal error, 2 usage error. `telemetry-check --rules` is a dependency-free structural sanity check, not a PromQL parser. Run `promtool check rules` separately when full PromQL syntax validation is required, then verify rule evaluation at the Prometheus API boundary.
 
 ## Triggers
 

telemetry/SKILL.md

@@ -40,7 +40,7 @@ Use this skill to operate the **telemetry stack** — Prometheus, the OpenTeleme
 
 ## The telemetry-check script
 
-`scripts/telemetry-check` is an agent-first, read-only checker. It parses Prometheus rules files with a bundled stdlib YAML reader and runs sanity checks mirroring `promtool check rules`; it extracts static targets from scrape configs and probes TCP reachability; and it emits bounded JSON. It never writes files and never sends data anywhere.
+`scripts/telemetry-check` is an agent-first, read-only checker. It parses Prometheus rules files with a bundled stdlib YAML reader and runs dependency-free structural sanity checks; it extracts static targets from scrape configs and probes TCP reachability; and it emits bounded JSON. It never writes files and never sends data anywhere.
 
 ```bash
 scripts/telemetry-check --help                      # no server needed
@@ -49,7 +49,7 @@ scripts/telemetry-check --scrape prometheus.yml --json   # probe static targets
 scripts/telemetry-check --targets targets.txt --timeout 5
 ```
 
-Exit codes: 0 all checks passed, 1 issues found or a fatal error, 2 usage error. The rule checks mirror promtool: exactly one of `record`/`alert` per rule, a non-empty expression with balanced delimiters, valid durations, recording-rule and label names, and string-only label values. Use `promtool check rules` for full PromQL parsing.
+Exit codes: 0 all checks passed, 1 issues found or a fatal error, 2 usage error. `telemetry-check --rules` checks structure only: exactly one of `record`/`alert` per rule, a non-empty expression with balanced delimiters, valid durations, recording-rule and label names, and string-only label values. Use `promtool check rules` separately for full PromQL parsing.
 
 ## Operating loop
 
@@ -63,7 +63,7 @@ Exit codes: 0 all checks passed, 1 issues found or a fatal error, 2 usage error.
 ## Prometheus: scrape, rules, relabeling, retention, HA
 
 - **Scrape config** (`scrape_configs`): one job per scrape group with a deliberate `scrape_interval`, `scrape_timeout` below it, and `metrics_path`. Prefer `static_configs` for known endpoints and service discovery (`*_sd_configs`) for dynamic ones. Verify the running config with `/api/v1/status/config` and targets with `/api/v1/targets?state=active`.
-- **Recording and alerting rules**: rules files are `groups` of `record` or `alert` rules with a PromQL `expr`, optional `for`/`keep_firing_for` durations, and `labels`/`annotations`. Validate every change with `promtool check rules` and with the bundled `telemetry-check --rules` before reload. Rules must be small, well-named, and reviewable — a 100-line expression is a debugging liability, not a rule.
+- **Recording and alerting rules**: rules files are `groups` of `record` or `alert` rules with a PromQL `expr`, optional `for`/`keep_firing_for` durations, and `labels`/`annotations`. Validate every change with `promtool check rules` for full PromQL parsing and with the bundled `telemetry-check --rules` for dependency-free structural sanity before reload. Rules must be small, well-named, and reviewable — a 100-line expression is a debugging liability, not a rule.
 - **Relabeling**: `relabel_configs` and `metric_relabel_configs` rewrite labels before ingestion. Use them to enforce label naming, drop high-cardinality or internal labels, and attach scrape metadata. Relabeling mistakes silently change series identity — verify with a targeted `curl` of `/metrics` and the target's `scrapeUrl` in `/api/v1/targets`.
 - **Retention**: `--storage.tsdb.retention.time` and `--storage.tsdb.retention.size` bound local block retention; blocks are 2h by default. Retention is a capacity decision (see `references/04-stack-integration-and-retention.md`), not a default to leave alone. Watch `prometheus_tsdb_head_series` and `prometheus_tsdb_compaction` for cardinality and compaction pressure.
 - **High availability (HA)**: two identically configured Prometheus instances with `--query.max-concurrency` headroom and consistent external labels let you shard or deduplicate at the query layer (Thanos, Mimir, or Grafana data sources). Alerting rules must not double-fire: HA pairs need a dedup layer or consistent labeling, and rule evaluation must stay consistent across replicas. Rule evaluation state (`for` counters) is local to each instance.

vite/scripts/test_vite_doctor.py

@@ -37,6 +37,39 @@ class ViteDoctorTest(unittest.TestCase):
             self.assertNotIn("do-not-print", result.stdout)
             self.assertNotIn("never-print", result.stdout)
 
+    def test_reports_resolved_package_and_binary_versions(self) -> None:
+        with tempfile.TemporaryDirectory() as directory:
+            project = Path(directory)
+            (project / "package.json").write_text(
+                json.dumps({"devDependencies": {"vite": "^6.0.0"}}), encoding="utf-8"
+            )
+            package_dir = project / "node_modules" / "vite"
+            package_dir.mkdir(parents=True)
+            (package_dir / "package.json").write_text(
+                json.dumps({"name": "vite", "version": "6.1.2"}), encoding="utf-8"
+            )
+            binary = project / "node_modules" / ".bin" / "vite"
+            binary.parent.mkdir(parents=True)
+            binary.write_text("#!/bin/sh\nprintf 'vite/6.1.2 node/22.0.0\\n'\n", encoding="utf-8")
+            binary.chmod(0o755)
+            result = self.run_doctor(project)
+            self.assertEqual(0, result.returncode)
+            payload = json.loads(result.stdout)
+            self.assertEqual("6.1.2", payload["vite_resolved"]["package"]["version"])
+            self.assertEqual("vite/6.1.2 node/22.0.0", payload["vite_resolved"]["executable"]["version"])
+
+    def test_reports_resolved_absence_without_installing(self) -> None:
+        with tempfile.TemporaryDirectory() as directory:
+            project = Path(directory)
+            (project / "package.json").write_text(
+                json.dumps({"dependencies": {"vite": "~5.4.0"}}), encoding="utf-8"
+            )
+            result = self.run_doctor(project)
+            self.assertEqual(0, result.returncode)
+            resolved = json.loads(result.stdout)["vite_resolved"]
+            self.assertFalse(resolved["package"]["available"])
+            self.assertFalse(resolved["executable"]["available"])
+
     def test_missing_project_is_bounded_error(self) -> None:
         result = self.run_doctor(Path("/path/that/does/not/exist"))
         self.assertEqual(1, result.returncode)

vite/scripts/vite-doctor

@@ -44,6 +44,29 @@ def bounded_version(command: list[str], timeout: float) -> dict[str, object]:
     return result
 
 
+def resolved_vite(project: Path, timeout: float) -> dict[str, object]:
+    """Report local package metadata and local .bin behavior without installing."""
+    package_path = project / "node_modules" / "vite" / "package.json"
+    package: dict[str, object] = {"available": package_path.is_file()}
+    if package_path.is_file():
+        try:
+            data = json.loads(package_path.read_text(encoding="utf-8"))
+            if isinstance(data, dict):
+                version = data.get("version")
+                if isinstance(version, str) and version:
+                    package["version"] = version
+                package["path"] = str(package_path)
+        except (OSError, json.JSONDecodeError) as exc:
+            package["error"] = f"cannot read installed package: {exc}"
+
+    binary_path = project / "node_modules" / ".bin" / "vite"
+    binary: dict[str, object] = {"available": binary_path.is_file()}
+    if binary_path.is_file():
+        binary["path"] = str(binary_path)
+        binary.update(bounded_version([str(binary_path), "--version"], timeout))
+    return {"package": package, "executable": binary}
+
+
 def main() -> int:
     parser = argparse.ArgumentParser(description=__doc__)
     parser.add_argument("--project", default=".", help="Vite project directory")
@@ -95,7 +118,7 @@ def main() -> int:
         },
         "node": bounded_version(["node", "--version"], args.timeout),
         "vite_dependency": dependencies,
-        "vite_installed": (project / "node_modules" / "vite" / "package.json").is_file(),
+        "vite_resolved": resolved_vite(project, args.timeout),
         "config_files": configs,
         "env_file_names": sorted(
             path.name for path in project.iterdir()