@r1z4x/tezgah 1.9.2 → 1.13.0

package/skills/tezgah-contract/SKILL.md

@@ -1,20 +1,25 @@
 ---
 name: tezgah-contract
 description: >
-  The full tezgah working contract. Load on demand when a tezgah session needs
-  the deep detail behind the always-on core: instruction fidelity (deliver the
-  whole ask, never a shortcut, no sycophantic openers), the code-graph-first
-  rule and its deferred tool loading, the dynamic graph harnesses, the two-tier
-  orchestration model with the cheap codegen bridge and its automatic
-  fallback, external-model consult, OpenResearch routing for research tasks,
-  and the exact kill switches. Use when the
-  compact core points here, or when a task needs the code graph, a subagent
-  fan-out, codegen, or a second opinion in full detail. Not for picking and
-  running a multi-agent harness - use `harness`.
+  Use when a session needs the code graph, a subagent fan-out, codegen, a second
+  opinion; alt ajan, kod grafiği, ikinci görüş. Not for harnesses - use
+  `harness`.
 ---
 
 # tezgah-contract
 
+## When to use
+
+The full tezgah working contract. Load on demand when a tezgah session needs the
+deep detail behind the always-on core: instruction fidelity (deliver the whole
+ask, never a shortcut, no sycophantic openers), the code-graph-first rule and
+its deferred tool loading, the dynamic graph harnesses, the two-tier
+orchestration model with the cheap codegen bridge and its automatic fallback,
+external-model consult, OpenResearch routing for research tasks, and the exact
+kill switches. Use when the compact core points here, or when a task needs the
+code graph, a subagent fan-out, codegen, or a second opinion in full detail. Not
+for picking and running a multi-agent harness - use `harness`.
+
 The always-on core is injected into every tezgah session; this skill is the
 deep detail, loaded on demand. `~/.config/tezgah/bin/consult` and
 `~/.config/tezgah/bin/codegen` are the tezgah-installed CLIs - use that stable
@@ -41,11 +46,11 @@ graph rule falls back to grep/find, the consult rule to a skipped second
 opinion - and carry on. Report the gap to the user once; do not chase it.
 
 Tezgah maintenance is in scope when the user asks for it, when the repo IS the
-tezgah checkout, or when tezgah's own check (`tezgah-setup --status`) is the
+tezgah checkout, or when tezgah's own check (`~/.config/tezgah/bin/tezgah-setup --status`) is the
 requested task.
 
 Using the skills is the user's work, not maintenance: before working a topic
-an installed skill covers, run `tezgah-skill <words>` (BM25 over every
+an installed skill covers, run `~/.config/tezgah/bin/tezgah-skill <words>` (BM25 over every
 installed skill's sections) and read only the `skill://<name>:<start>-<end>`
 range it returns - or the absolute path beside it on a host that does not
 resolve `skill://` - instead of loading the whole skill.
@@ -55,19 +60,19 @@ resolve `skill://` - instead of loading the whole skill.
 Every per-project tezgah artifact - plans, research lines, analysis, lessons -
 lives under `<repo>/.tezgah/`. Session start creates it, appends `/.tezgah/` and
 `/.codegraph/` to the project's `.gitignore` (user lines kept, nothing staged)
-and gives it a private git repository, so evidence that needs history - a
-research protocol committed before its results, a plan moved to `done/` - is
-committed with `git -C .tezgah ...` (or `tezgah-research commit <slug> "<msg>"`)
-and never enters the project's history. Never create `plans/`, `research/` or
-`analysis/` at the project root and never `git add -f` a path under `.tezgah/`:
-the gate refuses a write whose first path segment is one of those three unless
-the project itself already tracks files there. Off: `workspace-off`.
+and gives it a private git repository: evidence that needs history - a research
+protocol before its results, a plan moved to `done/` - is committed with
+`git -C .tezgah ...`, or plain `git add`/`git commit` when the project tracks
+it; `~/.config/tezgah/bin/tezgah-research commit` picks the right one. Never create `plans/`,
+`research/` or `analysis/` at the project root and never `git add -f` a path
+under `.tezgah/`: the gate refuses a write whose first path segment is one of
+those three unless the project already tracks files there. Off: `workspace-off`.
 
 ## Kill switches (auto-armed, tezgah roots only)
 
 Each one removes its own rule from the injected text, not just a status mark. In
 `~/.config/tezgah/`: `exec-mode.off`, `orchestrate-off`, `consult-off`,
-`research-off`, `ponytail-auto.off`, `adhd-off`, `spec-off`, `reminder-off`,
+`research-off`, `ponytail-auto.off`, `adhd-off`, `spec-off`, `design-off`, `reminder-off`,
 `verify-off`
 (the integrity rule: its prompt text, the shortcut denials and the Stop gate),
 `task-off` (all four refusals of the task rule: the phase, the allowlist, the
@@ -78,7 +83,7 @@ fallback alone), `lang-off` (the English-identifier rule in the gate),
 `workspace-off` (the gate's refusal of a root `plans/`, `research/` or
 `analysis/` write), `pretooluse-off` (the whole gate); per repo:
 `.no-ponytail`, `.no-adhd`, `.no-graph`, `.no-lessons`. The ponytail intensity
-level is not a switch: `tezgah-pony lite|full|ultra` (or `/tezgah:ponytail` on
+level is not a switch: `~/.config/tezgah/bin/tezgah-pony lite|full|ultra` (or `/tezgah:ponytail` on
 Claude) sets it and a bare call shows it.
 
 ## Task record: the active plan's phase and its path allowlist (auto-armed, tezgah roots only)
@@ -98,8 +103,8 @@ consulted (a shell line's targets are not read); and a write whose target is the
 record itself, refused whatever the phase and the globs say. The lifecycle is the
 session's, never a command handed to the user: it runs
 `~/.config/tezgah/bin/tezgah-task start|phase|allow|stop|status|review|close`
-itself, and the refusals name the move (`tezgah-task phase implementation`,
-`tezgah-task allow <glob> ... --why "<reason>"`). That move is vetted by the CLI,
+itself, and the refusals name the move (`~/.config/tezgah/bin/tezgah-task phase implementation`,
+`~/.config/tezgah/bin/tezgah-task allow <glob> ... --why "<reason>"`). That move is vetted by the CLI,
 not by who runs it: a writing phase needs every Acceptance item to name its
 command, `implementation` an answered spike and a clean tree to record
 `checkpoint:`, `allow` a `--why` it records as `allowed_why:`, `close NNN done`
@@ -239,20 +244,20 @@ blocked on a running slice, `wait` and ending the turn are both fine: the host
 wakes it on the result. The per-turn checks of what changed still run in the
 turn, in the background when they share no state. Only the heavy tier - the
 full suite, neuter, the e2e scripts - is joined at merge. A turn ends only
-when no item is ready, never on a question about a step it can take. Fan out only when the subtasks share no mutable file and no interface: if two of them would edit the same file, or one's answer decides the other's, keep them in one context or sequence them. Every writing brief names its `Owns:` globs - the files only that slice writes - and declares its checkout on a `Worktree: <abs path>` line; the gate refuses a sibling's write into those globs and a slice's write into the main checkout when its brief declares a worktree. The integrator owns the shared append points (CHANGELOG.md, MANIFEST, the citation baseline) and merges in the order `tezgah-task slice merge-plan` prints. Siblings message each other (omp `write agent://<id>`, Claude `SendMessage`) only on an interface or ownership change; status goes to the parent, and `tezgah-task slice board` shows every sibling's lease. Only a single item - one file, one
+when no item is ready, never on a question about a step it can take. Fan out only when the subtasks share no mutable file and no interface: if two of them would edit the same file, or one's answer decides the other's, keep them in one context or sequence them. Every writing brief names its `Owns:` globs - the files only that slice writes - and declares its checkout on a `Worktree: <abs path>` line; the gate refuses a sibling's write into those globs and a slice's write into the main checkout when its brief declares a worktree. The integrator owns the shared append points (CHANGELOG.md, MANIFEST, the citation baseline) and merges in the order `~/.config/tezgah/bin/tezgah-task slice merge-plan` prints. Siblings message each other (omp `write agent://<id>`, Claude `SendMessage`) only on an interface or ownership change; status goes to the parent, and `~/.config/tezgah/bin/tezgah-task slice board` shows every sibling's lease. Only a single item - one file, one
 bounded change, a strictly serial chain - is done directly; a list of
 independent items is never worked one by one on the main thread, however small
 each item is, and that holds at every phase: a plan's tasks, its acceptance
 commands and the sources of a survey fan out the same way.
 A slice that needs its own checkout: inside Orca (the session-start `Orca:`
 line) create it with `orca worktree create --name <slug> --parent-worktree
-active --json` and track it with `orca worktree ps --json` or `tezgah-status
+active --json` and track it with `orca worktree ps --json` or `~/.config/tezgah/bin/tezgah-status
 --orca` - a raw `git worktree add` gets no card, terminal tracking or agent
 status in Orca; outside Orca, `git worktree add`. Either way the brief names
 absolute paths under that checkout. A writing slice commits `wip: <step>`
 after each step, so a crash leaves it resumable. A stopped slice (quota, abort,
-cut off) is resumed - `tezgah-task slice resume <id>` - or re-dispatched, never
-silently absorbed inline; run `tezgah-task slice reconcile --prune` before the
+cut off) is resumed - `~/.config/tezgah/bin/tezgah-task slice resume <id>` - or re-dispatched, never
+silently absorbed inline; run `~/.config/tezgah/bin/tezgah-task slice reconcile --prune` before the
 turn that merged slices ends.
 Routing: `~/.config/tezgah/bin/tezgah-route "<brief>"` names the worker - tezgah-cheap, -standard or
 -frontier, or the specialist whose whole job the brief is (tezgah-tester,
@@ -260,13 +265,16 @@ Routing: `~/.config/tezgah/bin/tezgah-route "<brief>"` names the worker - tezgah
 never the host's generic task agent (overrides for stored data, credentials,
 security first; then a Jev judgement; the static phase table with no key). A report missing an output field, or an
 `ESCALATE:`, gets one narrower re-brief of the same role naming that field or judgement; only a second miss is
-restarted on tezgah-frontier with the original brief, never continued; the main thread never switches model (the cache is per model). A
+restarted on tezgah-frontier with the original brief, never continued; the main thread never switches model (the cache is per model).
+A subagent's question only the owner can answer (a class-F item, `ESCALATE: owner`) is relayed to
+the user in the approval batch: the orchestrator never answers it for the user
+and never escalates it to a stronger model. A
 code-discovery brief names codegraph's tools (`codegraph callers`, `callees`,
 `impact`, `node`, `files`, `codegraph_explore`) and says "answer from
 the graph, grep only for literal text"; never a grep-only explorer (observed).
 Subagents never orchestrate: no nested harnesses, no sub-subagents.
 
-### The verification batch: `tezgah-optimize`
+### The verification batch: `~/.config/tezgah/bin/tezgah-optimize`
 `~/.config/tezgah/bin/tezgah-optimize next [--files PATH ...]` answers, per command
 the active plan's Acceptance names, one of `run now`, `defer` or `already green` -
 the first from no measurement or a median below the in-turn bar, the second from a
@@ -365,7 +373,7 @@ test); a complex ask ships the lazy version and names the fuller one in the
 same reply. These rules are in force from the first turn; the full skill
 (Skill(tezgah:ponytail) on Claude, the installed `ponytail` skill elsewhere)
 holds the level table and the examples.
-Level: `tezgah-pony lite|full|ultra` (bare call shows it; stored in
+Level: `~/.config/tezgah/bin/tezgah-pony lite|full|ultra` (bare call shows it; stored in
 ~/.config/tezgah/ponytail.level, machine-wide until changed). The default `full`
 adds nothing to this reminder; a non-default level is named in it every turn.
 Off: user says "stop ponytail".
@@ -386,7 +394,11 @@ The reader has to act on the answer, and the friction between "got it" and
    line - never also narrate the plan as prose.
 4. End with the approval questions the Ask policy leaves (the executive mode's
    "Ask policy"), or with nothing when none is left. A step you can take
-   yourself is taken, never handed over.
+   yourself is taken, never handed over: "run `pytest -q` and tell me what it
+   says" is a step you run. In the host's plan mode nothing can run, and there
+   the plan is the deliverable: the approval question is the one question that
+   turn asks, every step waits for it, and nothing is reported as done or
+   tested, because nothing ran.
 5. Suppress tangents: finish the issue in hand, then raise the second as its own
    question. A question the reader raised mid-work is not a tangent - answer it
    and fold the result in.
@@ -410,7 +422,7 @@ After three "still broken" turns, name the suspect assumption and ask one
 diagnostic question. Before sending, delete an opening sentence that announces,
 a closing one that recaps, any by-the-way sidebar and any empty hedge. In force
 from the first answer; the full `i-have-adhd` skill holds the examples.
-Off: `tezgah-adhd off` (the kill switch file), or a repo's `.no-adhd`.
+Off: `~/.config/tezgah/bin/tezgah-adhd off` (the kill switch file), or a repo's `.no-adhd`.
 
 
 
@@ -433,7 +445,8 @@ intuitive". Such a request is NEVER built from a guess. Before any code:
 3. Ask at most three blocking questions, the ones that change the outcome and
    that no default may take. Every other question goes in the approval batch
    with a recommended default, and the work proceeds on the defaults in the
-   same turn (the executive mode's "Ask policy").
+   same turn (the executive mode's "Ask policy"); a class-F item waits for the
+   answer.
 4. Verify design, behavior and quality claims against an external source, never
    from memory alone: `~/.config/tezgah/bin/consult --online "<question>"` for a
    fast second opinion, or the OpenResearch CLI (`orx` on PATH, else
@@ -595,11 +608,11 @@ rewrite it plainly.
 **Merge authority: standing, not per-PR.** The user is not the approval step
 on a merge. Review first with a FRESH reviewer (never my own read of my own
 code), run the full suite, and if the review is clean and every test passes,
-merge and close the plan yourself (`tezgah-task close NNN done`, which also
+merge and close the plan yourself (`~/.config/tezgah/bin/tezgah-task close NNN done`, which also
 deactivates it and removes every merged worktree), then report the outcome. Nothing
 goes back to the user: a failing test you fix, and a critical or major finding
 left after round two you fix yourself, prove with a test and close with
-`tezgah-task close NNN done --resolved "<fix and test>"`. One review per plan, over its whole diff in the verification
+`~/.config/tezgah/bin/tezgah-task close NNN done --resolved "<fix and test>"`. One review per plan, over its whole diff in the verification
 phase; at most two rounds - only a confirmed critical or major finding opens
 round two; a minor or suggestion one is fixed in the session without a new
 round, or recorded fix-later only when it waits on a user decision (DECISION,
@@ -609,10 +622,15 @@ a third round.
 A round spawns its reviewers in ONE message, one per dimension (correctness
 and contract, security, tests and performance) or file group; a diff under 300
 changed lines gets one reviewer. Per-task work gets tests, not a reviewer, and
-`tezgah-task review` refuses a third round.
+`~/.config/tezgah/bin/tezgah-task review` refuses a third round. No fresh subagent, no review verdict:
+on a host or mode that cannot start a fresh reviewer, say so and ask the owner;
+never record a verdict from your own read. The author contests a confirmed
+finding only by citing evidence the reviewer could read (file:line); knowledge
+outside the files goes to the owner as a question, and the author never lowers
+a severity.
 
 **The process is yours: never hand a step back.** The orchestrator runs the
-plan lifecycle itself - `tezgah-task start`, every `phase` move, `review`,
+plan lifecycle itself - `~/.config/tezgah/bin/tezgah-task start`, every `phase` move, `review`,
 `close`, the merge, and removing a slice's worktree once its branch is merged -
 and never ends a reply with "run this command" or "shall I close it?" for a
 step it can take. A process parameter the user did not set (a sample size, a
@@ -637,13 +655,13 @@ whether the user already decided it (named it this session, or granted it).
 | C. Reversible choice the evidence settles | a fix's scope inside the ask, naming, a palette when tokens exist | decide from evidence; real taste goes in the batch with a default, taken this turn |
 | D. Intent fork | two readings of the ask with different deliverables | batch with a default; do the shared part first and proceed on the default |
 | E. Outward on the user's own remote | push, PR, tag, release, publishing the user's own package | act on a grant written in chat ("push without asking", "I approve", "bana sormadan pushla", "onay veriyorum"); else ask once per session, never again after a grant |
-| F. Never on a default | force push or history rewrite on a shared ref; deleting data the session did not make; production deploy, stop or migration; a credential, account or identity change; sending to a third party; a spend over `spend_cap` | do all other work first, ask, and wait: silence is no consent, and only an answer that names the action and its target clears it |
+| F. Never on a default | force push or history rewrite on a shared ref; deleting data the session did not make; production deploy, stop or migration; a credential, account or identity change; sending to a third party; a spend over `spend_cap`; building a plan this turn wrote from a research, analysis, review or plan ask; choosing a variant or option a research, analysis or review recommends; a way around a tezgah refusal (another folder, a hidden dir, a hatch the owner did not grant); deciding about another session's work (its line, plan or branch) | do all other work first, ask, and wait: silence is no consent, and only an answer that names the action and its target clears it |
 | G. ACCESS | a credential or grant no tool supplies | take every route that needs none first, then ask once, naming what it unlocks |
 
 A grant is read from the user's prompt and recorded for the session; "artık
 bana sor", "ask me again" or a later "don't push" lifts it. The batch is one
 block in the reply language: one "Approval questions"/"Onay için sorular" heading, one line saying
-the work proceeds on the defaults when no answer comes, then numbered items -
+the work proceeds on the defaults when no answer comes (a class-F item waits for its answer), then numbered items -
 the question in bold, one line of context, "Recommended:"/"Öneri:" the default, and
 the other option. Class-F items come first, marked as waiting; the defaulted
 items follow, with no count cap, because they do not block. An ask tool (omp
@@ -783,7 +801,7 @@ stays on the codegraph index.
 **Lock the line to the question asked.** Restate the user's question verbatim as
 the line's scope (`--ask`) and name what is in it and what is out (`--in`,
 `--out`: state.json `scope`). Every finding answers an in-scope item - a claim's
-`trace` names its `S<n>`, and `tezgah-research check` refuses one that names none -
+`trace` names its `S<n>`, and `~/.config/tezgah/bin/tezgah-research check` refuses one that names none -
 and a finding that answers nothing asked is dropped, not reported as a bonus. Do
 not widen the question, add sub-questions or chase an adjacent topic; a tangent
 worth having is one line under Open questions for the user to pick. The question
@@ -798,12 +816,12 @@ stating its confidence (high, medium or low, and why); a summary of summaries is
 not an answer.
 
 **New ideas are an exploratory line.** When the user asks for new ideas, methods
-or approaches rather than an answer, open `tezgah-research init --method
+or approaches rather than an answer, open `~/.config/tezgah/bin/tezgah-research init --method
 exploratory` with `--ask` and its arena - `--arena` (the problem, verbatim), `--in`,
 `--out`, `--budget`, and `--evaluator` with `--metric` when a number can judge a candidate -
 committed before the first idea; every other line keeps the question lock above.
 Ideas, stage moves and judged matches are rows (`idea`, `stage`, `match`), a
-ranking is a prior and never a verdict, and `tezgah-research board <slug>` names
+ranking is a prior and never a verdict, and `~/.config/tezgah/bin/tezgah-research board <slug>` names
 each idea's next step.
 
 When the task is research and the OpenResearch CLI is installed, drive it
@@ -811,8 +829,8 @@ through that CLI instead of ad-hoc local scripting. Resolve it as `orx` on PATH,
 else `~/.cargo/bin/orx` (the installer's location, which a non-interactive shell
 does not put on PATH). Load the operating manual first:
 the `orx` skill if the host has it, otherwise run `orx skill` from the shell; then
-the module the method needs - `orx skill lit-review` for sources,
-`orx skill experiment-tree` and `orx skill evidence` for a measured line. On a
+the module the method needs - `orx skill lit-review` for sources, `orx skill experiment-tree`,
+`orx skill orx-results` and `orx skill orx-logs` for a measured line. On a
 measured line its cardinal rules are not style preferences - they
 are what keeps results comparable, and breaking one silently invalidates the run:
 never edit a node once a run has answered it (branch a child instead); the run
@@ -844,7 +862,7 @@ in the report, a decision or a claim `trace`, or written `A<n> not delivered:
 <reason>`. A design or plan the user will choose between is produced as >= 3
 variants in
 `decisions/<id>/` - `criteria.json` committed before any cell, `variants.jsonl` (V0
-the status quo), cells appended by `tezgah-research compare`, `decision.md` naming
+the status quo), cells appended by `~/.config/tezgah/bin/tezgah-research compare`, `decision.md` naming
 the chosen id, each rejected id with the criterion that ruled it out, and a `flip:`
 condition (an analysis answers its question once); a new version of a line is
 opened `init --supersedes <old>` and carries
@@ -852,7 +870,7 @@ the old one as a variant. Code or config variants are sibling orx nodes under on
 head node. Literature is found with `orx discover` and read with `orx paper`; an
 agent's summary is indexed as `agent-report` and never alone carries a literature
 claim. At most one line is open at a time; `init --allow-open "<reason>"` is refused
-beside a line `check` fails, and `tezgah-research close <slug> --limit "<reason>"`
+beside a line `check` fails, and `~/.config/tezgah/bin/tezgah-research close <slug> --limit "<reason>"`
 concludes a line as a deliberate limit, writing what was left.
 Load the `research` skill for the two-loop rhythm, the ideation step, the
 six-dimension review a claim passes before it is reported, and the provenance tags
@@ -956,7 +974,7 @@ best, cited. Read the `product-analysis` skill for the artifact shape and the
 scorecard - the same 1-5 anchors as the `research` skill, so two sessions'
 analyses stay comparable - and `feature-audit` for the layer-coherence matrices
 when the ask is one feature. A new capability built from data or an ask runs the
-`product-flow` skill: `tezgah-research next --topic <t>` is the step source, and
+`product-flow` skill: `~/.config/tezgah/bin/tezgah-research next --topic <t>` is the step source, and
 its first missing or due step is the next one. Kill switch: `research-off`.
 
 

package/statusline.py

@@ -3,6 +3,10 @@
 
   python3 statusline.py            # Claude Code (or any Claude-format status line)
   python3 statusline.py --cursor   # Cursor CLI (same stdin shape, no Orca passthrough)
+  python3 statusline.py --qwen     # Qwen Code `ui.statusLine` command (same fields read)
+  python3 statusline.py --droid    # Factory Droid `statusLine` command (`current_dir`)
+  python3 statusline.py --copilot  # Copilot CLI `statusLine` command (fields undocumented)
+  python3 statusline.py --antigravity  # Antigravity CLI `statusLine` command (`workspace`)
 
 Claude Code's statusLine pipes session JSON on stdin; Cursor's spec is aligned
 with it. This wraps Orca's own status line for Claude, then appends the tezgah
@@ -35,8 +39,9 @@ except Exception as exc:
 
 HOME = os.path.expanduser("~")
 ORCA = os.path.join(HOME, ".orca", "agent-hooks", "claude-statusline.sh")
-HOST = "cursor" if ("--cursor" in sys.argv or
-                    os.environ.get("TEZGAH_STATUS_HOST") == "cursor") else "claude"
+HOST = next((h for h in ("cursor", "qwen", "droid", "copilot", "antigravity")
+             if "--" + h in sys.argv
+             or os.environ.get("TEZGAH_STATUS_HOST") == h), "claude")
 
 data = sys.stdin.read()
 try:
@@ -54,8 +59,11 @@ if HOST == "claude" and os.access(ORCA, os.X_OK):
     except Exception:
         orca_out = ""
 
-cwd = ((payload.get("workspace") or {}).get("current_dir")
-       or payload.get("cwd") or "")
+# Droid 0.251.0 sends `current_dir` at the top level (its status line snapshot
+# carries session_id, transcript_path, current_dir, workspace, model)
+workspace = payload.get("workspace")
+cwd = ((workspace if isinstance(workspace, dict) else {}).get("current_dir")
+       or payload.get("current_dir") or payload.get("cwd") or "")
 try:
     real = os.path.realpath(cwd) if cwd else ""
 except OSError:
@@ -113,11 +121,14 @@ def claude_used():
     return used
 
 
-seen = used_kinds(payload.get("session_id")) if HOST == "cursor" else claude_used()
-# Cursor's line reads tezgah's store, which sees the tool calls its hook fires on
-# and nothing else; Claude's transcript carries the skill reads too.
-observable = TOOL_USE_MEASURES if HOST == "cursor" else None
-segs = health_segments(real or os.getcwd(), payload.get("session_id"),
+# Copilot documents its status line input only as "session JSON", so its
+# camelCase spelling is read too
+session_id = payload.get("session_id") or payload.get("sessionId")
+seen = used_kinds(session_id) if HOST != "claude" else claude_used()
+# Cursor's, Qwen's, Droid's, Copilot's and Antigravity's lines read tezgah's store, which sees the tool calls their
+# hook fires on and nothing else; Claude's transcript carries the skill reads too.
+observable = TOOL_USE_MEASURES if HOST != "claude" else None
+segs = health_segments(real or os.getcwd(), session_id,
                        used_override=seen, observable=observable)
 # Claude Code and Cursor render ANSI; let a user or a plain terminal opt out.
 color = color_default()

package/workflows/graph-review.js

@@ -114,7 +114,18 @@ const unknown = DIMENSIONS.filter((d, i) => !reviewed[i]).map(d => `review:${d.k
 const reviews = reviewed.filter(Boolean)
 
 const rank = { high: 0, medium: 1, low: 2 }
-const all = reviews.flatMap(r => r.findings || []).sort((a, b) => rank[a.severity] - rank[b.severity])
+// two lenses often raise one defect: merge on (file, line, lowercased title), keep the higher severity
+const byKey = new Map()
+let raised = 0
+reviewed.forEach((r, i) => ((r && r.findings) || []).forEach(f => {
+  raised++
+  const key = `${f.file}\u0000${f.line || ''}\u0000${String(f.title).trim().toLowerCase()}`
+  const prev = byKey.get(key)
+  const keep = prev && rank[prev.severity] <= rank[f.severity] ? prev : f
+  byKey.set(key, { ...keep, dimensions: [...new Set([...((prev && prev.dimensions) || []), DIMENSIONS[i].key])] })
+}))
+const all = [...byKey.values()].sort((a, b) => rank[a.severity] - rank[b.severity])
+const caps = { max_verified: MAX_VERIFIED, raised, deduplicated: raised - all.length }
 if (!all.length) {
   const note = !unknown.length ? 'all four dimensions came back clean'
     : !reviews.length ? 'every dimension failed - nothing was reviewed; unknown, not clean'
@@ -124,7 +135,7 @@ if (!all.length) {
 
 const toVerify = all.slice(0, MAX_VERIFIED)
 if (all.length > toVerify.length) {
-  log(`${all.length} findings raised; verifying the ${toVerify.length} most severe. NOT verified (reported as unverified): ${all.slice(MAX_VERIFIED).map(f => f.title).join('; ')}`)
+  log(`${all.length} distinct findings (${caps.deduplicated} duplicates merged); verifying the ${toVerify.length} most severe. NOT verified (reported as unverified): ${all.slice(MAX_VERIFIED).map(f => f.title).join('; ')}`)
 }
 
 phase('Verify')
@@ -167,4 +178,5 @@ return {
   unverified: unsettled.map(v => ({ ...v.finding, verdict: 'UNVERIFIED - every refuter failed' }))
     .concat(all.slice(MAX_VERIFIED).map(f => ({ ...f, verdict: 'UNVERIFIED - budget cap' }))),
   unknown,
+  caps,
 }

package/bin/tezgah-skill.py

@@ -1,59 +0,0 @@
-#!/usr/bin/env python3
-"""tezgah-skill [-k N] [--json] [--root DIR] QUERY... - find the skill section
-that answers a topic.
-
-The roster a session meets is hundreds of one-line names, so the skill that
-holds the answer is a guess unless something searches the bodies. This is that
-search: every installed skill root on the machine (the plugin's own, omp's user
-and custom-directories corpora, Claude/Codex/Agents/opencode), indexed by
-heading, ranked by the same BM25 the per-turn lessons block uses. Each hit is a
-section, not a file:
-
-  skill://attack-jwt:26-122  /abs/SKILL.md  JWT Token Attack
-
-The `skill://<name>:<start>-<end>` address is what omp's read tool resolves
-(line selectors included); the absolute path is for the hosts that have no
-skill:// transport, and is also the tiebreaker where two roots hold different
-skills under one name (the search reports the first root's copy, omp's own
-precedence order - it does not resolve the collision for you).
-
---root DIR adds a directory to the discovered roots (a project's vendored
-skills); --json prints the machine shape. Exit 0 hits, 1 none, 2 usage.
-"""
-import argparse
-import json
-import os
-import sys
-
-HERE = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
-sys.path.insert(0, os.path.join(HERE, "hooks"))
-import tezgah_skill_pick as sp  # noqa: E402
-
-
-def main(argv=None):
-    parser = argparse.ArgumentParser(
-        prog="tezgah-skill", description=__doc__.splitlines()[0])
-    parser.add_argument("query", nargs="+", help="the topic to search for")
-    parser.add_argument("-k", type=int, default=5, metavar="N",
-                        help="sections to print (default 5)")
-    parser.add_argument("--root", action="append", default=[], metavar="DIR",
-                        help="an extra skills directory to index (repeatable)")
-    parser.add_argument("--json", action="store_true",
-                        help="print [{skill, uri, path, title, start, end}]")
-    args = parser.parse_args(argv)
-    query = " ".join(args.query)
-    hits = sp.search(query, k=max(1, args.k),
-                     roots=(sp.skill_roots(args.root) if args.root else None))
-    if args.json:
-        print(json.dumps([{"skill": h[0],
-                           "uri": "skill://%s:%d-%d" % (h[0], h[3], h[4]),
-                           "path": h[1], "title": h[2],
-                           "start": h[3], "end": h[4]} for h in hits], indent=1))
-    else:
-        for skill, path, title, start, end in hits:
-            print("skill://%s:%d-%d\t%s\t%s" % (skill, start, end, path, title))
-    return 0 if hits else 1
-
-
-if __name__ == "__main__":
-    sys.exit(main())