@azure-id/orc 1.9.0 → 1.9.2

package/bin/webui/js/panels/overview.js

@@ -66,8 +66,9 @@ const FINDING_ROUTE = {
   "lane-keys-drifted": { panel: "maintenance", cta: "overview.item.laneKeysDrifted.cta" },
   // v1.8.0. A DRIFTED code graph is cleared by the free `orc graph update`, which
   // is a button on the Knowledge panel's code graph card — the panel that can
-  // CLEAR it, not the default.
-  "graph-drifted": { panel: "knowledge", cta: "overview.item.graphDrifted.cta" },
+  // CLEAR it, not the default. Since v1.9.2 it opens the Code graph TAB, where
+  // the state ladder carries that button.
+  "graph-drifted": { panel: "knowledge", tab: "graph", cta: "overview.item.graphDrifted.cta" },
   // v1.3.0. The rule again, and cleanly: every one of these is cleared on the
   // CLI Hook Interface panel — the board is where an orphaned component is
   // removed, the caution strip is where an invalid layout is named, and the
@@ -97,6 +98,13 @@ const FINDING_ROUTE = {
 const DEFAULT_FINDING_ROUTE = { panel: "maintenance", cta: "overview.item.doctor.cta" };
 const findingRoute = (id) => FINDING_ROUTE[id] || DEFAULT_FINDING_ROUTE;
 
+// Go to a panel, and — when the route names one — to its tab. Only Knowledge
+// has a tab a finding can name (KN_TAB, which survives a re-render).
+function goRoute(panel, tab) {
+  if (panel === "knowledge" && tab && typeof KN_TAB !== "undefined") KN_TAB = tab;
+  location.hash = "#/" + panel;
+}
+
 PANELS.overview = function (host) {
   head(host, t("overview.title"), t("overview.sub"));
   section(
@@ -317,7 +325,7 @@ PANELS.overview = function (host) {
           if (r.panel) {
             const go = el("button", "btn btn-ghost btn-sm", t(r.cta));
             go.type = "button";
-            go.addEventListener("click", () => (location.hash = "#/" + r.panel));
+            go.addEventListener("click", () => goRoute(r.panel, r.tab));
             detail.append(go);
           } else {
             detail.append(el("div", "note", t("overview.attention.nothingToDo")));
@@ -387,6 +395,7 @@ function attentionCard(d, findings) {
         // as the title beats paraphrasing it into something less exact.
         title: f.message,
         panel: r.panel,
+        tab: r.tab,
         cta: t(r.cta),
       });
     }
@@ -458,7 +467,7 @@ function attentionCard(d, findings) {
     // The CLI's own words for WHY, kept verbatim under our explanation.
     if (it.evidence) mid.append(el("div", "todo-evidence", it.evidence));
     row.append(mid, el("span", "todo-cta", it.cta));
-    row.addEventListener("click", () => (location.hash = "#/" + it.panel));
+    row.addEventListener("click", () => goRoute(it.panel, it.tab));
     list.append(row);
   }
   if (items.length) c.append(list);

package/mock-run/context-combiner.md

@@ -1,100 +1,100 @@
-# Mock run — the context combiner
-
-> Two analyses of two related documents, merged into one spec — and it proves
-> that nothing was lost.
-
-There is no slash command for this. It is offered by `/orc-analyze` when two or
-more related analyses already exist.
-
----
-
-## 1. What it does
-
-You analysed the refund policy PDF last week. Today you analysed the support
-escalation doc. Both talk about refunds. Building from either one alone means
-building half the thing.
-
-The combiner pools **every** requirement from **every** source and gives each
-one exactly one outcome. Then it counts. If the count is not 100%, it does not
-hand off.
-
----
-
-## 2. The run
-
-```
-/orc-analyze  …  Phase F:
-
-  Two related analyses found. Merge them into one spec?
-  · refund-policy       11 requirements   2026-08-04
-  · support-escalation   7 requirements   2026-08-12
-
-> yes
-```
-
-```
-Dispatching orc-context-combiner-opus-5-high …
-returned as: claude-opus-5 / high        ✓
-
-Phase B — are these really related?
-  shared files       api/refunds/ (both), web/refunds/ (both)
-  shared subject     refund state and who is told about it
-  Verdict: related. Continuing.
-
-Phase C — pooled 18 requirements, reconciled one at a time
-
-  exact duplicate    R-04 = S-02  "refund state must be visible to support"
-                     → ONE row, both sources cited
-  partial overlap    R-07 "notify the customer" vs S-05 "notify support"
-                     → SPLIT into two rows, never collapsed into "notify"
-  conflict           R-09 says refunds are final; S-06 describes a re-open
-                     → CONFLICT, raised to you (below)
-  ordering           S-01 must happen before R-02 (it creates the state)
-
-Phase D — one question at a time
-
-  ❓ R-09 vs S-06 — can a closed refund be re-opened?
-     R-09 (policy PDF, p.4): "a completed refund is final"
-     S-06 (escalation doc, §2): "support may re-open within 14 days"
-     ➡️  The escalation doc is newer. I recommend S-06 wins, with R-09 kept
-        as a note. Your call.
-
-  > S-06 wins, and add the 14 days as a hard rule
-
-Phase E — conservation gate
-  source requirements   18
-  rows in the merged spec 19   (one split into two)
-  every source id has exactly one outcome:
-     kept 15 · merged 2 · split 1→2 · resolved-by-you 1 · dropped 0
-  coverage_pct: 100        → handoff allowed
-
-Phase F — written
-  combined-report.md
-  combined-requirement-spec.md          (a normal spec, plus the source map)
-
-Evidence freshness: 2 anchors from last week no longer match HEAD.
-  api/refunds/create.ts:31 → now :44     (flagged, not silently fixed)
-```
-
----
-
-## 3. What to notice
-
-- **Nothing may vanish quietly.** Below 100% coverage there is no handoff.
-  Dropping a requirement is allowed — but only as your explicit decision, and
-  it is recorded as one.
-- **A partial overlap is split, never collapsed.** Collapsing two similar
-  requirements into one shorter sentence is how scope disappears.
-- **Old evidence is re-checked against HEAD**, because an anchor that was true
-  last week is not a fact today.
-- **The merged spec is a normal spec.** The planner and the build pipeline do
-  not know or care that it came from two documents.
-- **Full lane only.** There is no mini version of this, and it never builds
-  anything or spawns anything itself.
-
----
-
-## 4. Related
-
-- Where it starts: [`/orc-analyze`](../templates/skills/orc-analyze/examples/analyze-mock.md)
-- What happens next: [`/orc-plan`](orc-plan.md)
+# Mock run — the context combiner
+
+> Two analyses of two related documents, merged into one spec — and it proves
+> that nothing was lost.
+
+There is no slash command for this. It is offered by `/orc-analyze` when two or
+more related analyses already exist.
+
+---
+
+## 1. What it does
+
+You analysed the refund policy PDF last week. Today you analysed the support
+escalation doc. Both talk about refunds. Building from either one alone means
+building half the thing.
+
+The combiner pools **every** requirement from **every** source and gives each
+one exactly one outcome. Then it counts. If the count is not 100%, it does not
+hand off.
+
+---
+
+## 2. The run
+
+```
+/orc-analyze  …  Phase F:
+
+  Two related analyses found. Merge them into one spec?
+  · refund-policy       11 requirements   2026-08-04
+  · support-escalation   7 requirements   2026-08-12
+
+> yes
+```
+
+```
+Dispatching orc-context-combiner-opus-5-high …
+returned as: claude-opus-5-5 / high        ✓
+
+Phase B — are these really related?
+  shared files       api/refunds/ (both), web/refunds/ (both)
+  shared subject     refund state and who is told about it
+  Verdict: related. Continuing.
+
+Phase C — pooled 18 requirements, reconciled one at a time
+
+  exact duplicate    R-04 = S-02  "refund state must be visible to support"
+                     → ONE row, both sources cited
+  partial overlap    R-07 "notify the customer" vs S-05 "notify support"
+                     → SPLIT into two rows, never collapsed into "notify"
+  conflict           R-09 says refunds are final; S-06 describes a re-open
+                     → CONFLICT, raised to you (below)
+  ordering           S-01 must happen before R-02 (it creates the state)
+
+Phase D — one question at a time
+
+  ❓ R-09 vs S-06 — can a closed refund be re-opened?
+     R-09 (policy PDF, p.4): "a completed refund is final"
+     S-06 (escalation doc, §2): "support may re-open within 14 days"
+     ➡️  The escalation doc is newer. I recommend S-06 wins, with R-09 kept
+        as a note. Your call.
+
+  > S-06 wins, and add the 14 days as a hard rule
+
+Phase E — conservation gate
+  source requirements   18
+  rows in the merged spec 19   (one split into two)
+  every source id has exactly one outcome:
+     kept 15 · merged 2 · split 1→2 · resolved-by-you 1 · dropped 0
+  coverage_pct: 100        → handoff allowed
+
+Phase F — written
+  combined-report.md
+  combined-requirement-spec.md          (a normal spec, plus the source map)
+
+Evidence freshness: 2 anchors from last week no longer match HEAD.
+  api/refunds/create.ts:31 → now :44     (flagged, not silently fixed)
+```
+
+---
+
+## 3. What to notice
+
+- **Nothing may vanish quietly.** Below 100% coverage there is no handoff.
+  Dropping a requirement is allowed — but only as your explicit decision, and
+  it is recorded as one.
+- **A partial overlap is split, never collapsed.** Collapsing two similar
+  requirements into one shorter sentence is how scope disappears.
+- **Old evidence is re-checked against HEAD**, because an anchor that was true
+  last week is not a fact today.
+- **The merged spec is a normal spec.** The planner and the build pipeline do
+  not know or care that it came from two documents.
+- **Full lane only.** There is no mini version of this, and it never builds
+  anything or spawns anything itself.
+
+---
+
+## 4. Related
+
+- Where it starts: [`/orc-analyze`](../templates/skills/orc-analyze/examples/analyze-mock.md)
+- What happens next: [`/orc-plan`](orc-plan.md)