@r1z4x/tezgah 1.9.2 → 1.13.0

package/docs/index.json

@@ -269,7 +269,13 @@
         "what lights the research mark and how is the layer switched off",
         "why may a new research line not be opened while another is unfinished",
         "what does tezgah-research next print for a product flow, and when is a decision due for re-measure",
-        "how does an exploratory line run a campaign of new ideas (arena, stage funnel, tournament, board, dedup, yield)"
+        "how does an exploratory line run a campaign of new ideas (arena, stage funnel, tournament, board, dedup, yield)",
+        "how is a claim's certainty computed (rules 8 start level, steps, ceilings)",
+        "how do I record a citation receipt, a source capture or a search (cite, fetch, search)",
+        "what is a question class and what does init --class print",
+        "what does release-check do and what does calibration print",
+        "how does the instrument ledger validate an LLM judge (instrument, gold, label, switch)",
+        "what formats does a new line write by hand (INDEX note path, provenance values, review dimensions, deliverable)"
       ],
       "answers_tr": [
         "bir araştırma hattı nerede yaşar ve ne tutar",
@@ -279,7 +285,13 @@
         "araştırma işaretini ne yakar ve katman nasıl kapatılır",
         "başka biri bitmemişken neden yeni bir araştırma hattı açılamaz",
         "tezgah-research next bir ürün akışı için ne yazdırır ve bir karar ne zaman yeniden ölçülmeli",
-        "keşif (exploratory) hattı yeni fikir kampanyasını nasıl yürütür (arena, aşama hunisi, turnuva, board, dedup, yield)"
+        "keşif (exploratory) hattı yeni fikir kampanyasını nasıl yürütür (arena, aşama hunisi, turnuva, board, dedup, yield)",
+        "bir iddianın kesinlik düzeyi nasıl hesaplanır (rules 8 başlangıç düzeyi, adımlar, tavanlar)",
+        "bir atıf makbuzu, kaynak yakalaması ya da arama nasıl kaydedilir (cite, fetch, search)",
+        "soru sınıfı nedir ve init --class ne yazdırır",
+        "release-check ne yapar ve calibration ne yazdırır",
+        "araç defteri bir LLM yargıcını nasıl doğrular (instrument, gold, label, switch)",
+        "yeni bir hat elle hangi biçimleri yazar (INDEX note yolu, provenance değerleri, review boyutları, deliverable)"
       ],
       "sources": [
         "hooks/tezgah_research.py",
@@ -288,7 +300,10 @@
         "hooks/tezgah_policy.py",
         "hooks/tezgah_context.py",
         "skills/research/SKILL.md",
-        "tests/test_research.py"
+        "tests/test_research.py",
+        "hooks/tezgah_research_capture.py",
+        "hooks/tezgah_research_evidence.py",
+        "hooks/tezgah_research_stats.py"
       ]
     },
     {
@@ -302,7 +317,9 @@
         "how do I add a skill without breaking the router or the install report",
         "which skill designs a metric dashboard and where do its data-view rules live",
         "does the local skill search reach design-library's nested entries",
-        "which skill carries a new metric dashboard or feature from research to re-measure"
+        "which skill carries a new metric dashboard or feature from research to re-measure",
+        "which floor wins between a repository's design.md and the design contract",
+        "what does tezgah-design slop run and where does its verdict go"
       ],
       "answers_tr": [
         "burada beceri nedir ve bir hosta nasıl ulaşır",
@@ -310,18 +327,23 @@
         "yönlendiriciyi veya kurulum raporunu bozmadan nasıl beceri eklerim",
         "metrik dashboard tasarımını hangi beceri yapar ve veri görünümü kuralları nerede",
         "yerel beceri araması design-library'nin iç girdilerine ulaşır mı",
-        "yeni bir metrik dashboard'u veya özelliği araştırmadan yeniden ölçüme hangi beceri taşır"
+        "yeni bir metrik dashboard'u veya özelliği araştırmadan yeniden ölçüme hangi beceri taşır",
+        "bir deponun design.md dosyası ile tasarım sözleşmesi arasında hangi katman kazanır",
+        "tezgah-design slop neyi çalıştırır ve kararı nereye yazar"
       ],
       "sources": [
         "bin/tezgah-setup",
+        "bin/tezgah-design",
         "skills/",
         "skills/design-library/SOURCE",
+        "skills/hallmark/SOURCE",
         "tests/routing-fixtures.md",
         "commands/",
         "NOTICE",
         "tests/test_setup.py",
         "tests/test_skills.py",
         "hooks/tezgah_skill_pick.py",
+        "hooks/tezgah_integrity.py",
         "skills/design-contract/data-views.md",
         "skills/product-flow/SKILL.md"
       ]
@@ -386,7 +408,8 @@
         "something is broken what do I check first",
         "how do I turn on taste signal capture and measure my corrections",
         "how does taste learn my coding preferences and inject them",
-        "how do I resume or clean up a delegated slice after a crash or a quota stop"
+        "how do I resume or clean up a delegated slice after a crash or a quota stop",
+        "how do I turn on the open-code-review spec for a plan's review"
       ],
       "answers_tr": [
         "bunu bir makineye nasıl kurar, doğrular ve yükseltirim",
@@ -396,7 +419,8 @@
         "bir şey bozuk, önce neyi kontrol etmeliyim",
         "zevk sinyali kaydını nasıl açar ve düzeltmelerimi nasıl ölçerim",
         "taste kodlama tercihlerimi nasıl öğrenir ve oturuma nasıl ekler",
-        "bir çökme veya kota durmasından sonra devredilen bir dilimi nasıl sürdürür veya temizlerim"
+        "bir çökme veya kota durmasından sonra devredilen bir dilimi nasıl sürdürür veya temizlerim",
+        "bir planın incelemesi için open-code-review spesifikasyonunu nasıl açarım"
       ],
       "sources": [
         "bin/tezgah-setup",
@@ -413,7 +437,9 @@
         "hooks/tezgah_taste_ledger.py",
         "bin/tezgah-taste",
         "hooks/tezgah_task.py",
-        "bin/tezgah-task"
+        "bin/tezgah-task",
+        "bin/tezgah-review-quote",
+        "bin/tezgah-ocr-review"
       ]
     },
     {

package/docs/judge.md

@@ -118,8 +118,10 @@ The CLI runs headless in an empty temp dir. Its flags are `SESSION_ARGV`
 (`hooks/tezgah_judge.py::SESSION_ARGV`). The omp and claude runs drop tools,
 rules, skills, extensions, MCP servers and settings. The other three have no flag
 that drops their tools or takes a system prompt. They run with the least their
-`--help` offers: opencode `--pure`, cursor-agent `--mode ask`, codex
-`-s read-only --ephemeral`. Their prompt starts with the system prompt.
+`--help` offers: cursor-agent `--mode ask`, codex `-s read-only --ephemeral`,
+and opencode `--format json`. The 2.0 CLI dropped the `--pure` its 1.18
+offered, so the judge's inline config stays what denies its tools. Their prompt
+starts with the system prompt.
 `opencode run` ran a shell command its prompt asked for in a probe on
 2026-10-09. So it also gets an inline config that denies every tool
 (`SESSION_ENV`, `hooks/tezgah_judge.py::SESSION_ENV`). With it, the same probe

package/docs/layers.md

@@ -56,7 +56,7 @@ Must not own the user's rules, the evidence of the turn or the refusal. A
 runtime runs what the model asks; nothing inside it stops the model, which is
 the whole reason tezgah exists ([architecture](architecture.md)).
 
-Here the six hosts are the runtimes, one config dir per host
+Here the fourteen hosts (claude, codex, cursor, opencode, dsh, omp, qwen, droid, commandcode, copilot, gemini, antigravity, goose, amp) are the runtimes, one config dir per host
 (`hooks/tezgah_paths.py::HOST_DIRS`) with one presence test (`host_installed`
 `hooks/tezgah_paths.py::host_installed`), and the adapter under `hosts/<name>/` holds the
 host's envelope and nothing else ([hosts](hosts.md)). The README's own intro
@@ -94,8 +94,8 @@ frameworks.
 | agent framework | is it composed *from* elsewhere, or does it compose? A framework is composed from building blocks and stays a framework agent | tezgah plugs into its extension points, supplies none |
 | SDK | does it leave the iteration to its caller? A client library gives a call and stops | tezgah ships no client; it reads a host's event JSON on stdin (`hosts/codex/hook.py:1-2`) |
 | IDE plugin | is it a guest inside another program's surface? It draws and forwards and owns no task runtime | `hosts/opencode/plugins/tezgah.js:1-12` is one, and is a plugin |
-| eval harness | does it produce a score over a task set? It measures and enforces nothing | an eval scaffold is vendored as the `lm-evaluation-harness` skill body (`skills/ai-research/11-evaluation/lm-evaluation-harness/SKILL.md:11`), and this project's measurements live apart from the layer (`docs/README.md:88-89`) |
-| orchestrator | does it split one request across many runs and merge them? A harness runs one job to a report | the `harness` skill's route table (`skills/harness/SKILL.md:2-8`) and the graph workflows (`hooks/tezgah_policy.py::WORKFLOWS`) |
+| eval harness | does it produce a score over a task set? It measures and enforces nothing | an eval scaffold is vendored as the `lm-evaluation-harness` skill body (`skills/ai-research/11-evaluation/lm-evaluation-harness/ENTRY.md:11`), and this project's measurements live apart from the layer (`docs/README.md:88-89`) |
+| orchestrator | does it split one request across many runs and merge them? A harness runs one job to a report | the `harness` skill's route table (`skills/harness/SKILL.md:41-53`) and the graph workflows (`hooks/tezgah_policy.py::WORKFLOWS`) |
 | MCP | does it only carry a call and its result? Then it is transport, not a layer with policy or evidence | the section below |
 
 ## Why tezgah is not an agent harness
@@ -131,7 +131,7 @@ by solving the task.
 |---|---|---|
 | tezgah's own | the wrapper around a host - the injected contract, the per-turn text still travelling in the `<harness-reminder>` envelope (`hooks/tezgah_policy.py::PROMPT_REMINDER`), the gate and the ledger | [glossary](glossary.md#harness) |
 | the literature's | the host itself: a "complete agent runtime", which the README's intro also calls a harness for dsh (`README.md:27-28`) | [hosts](hosts.md) |
-| the skill's | multi-agent harness selection: which graph workflow or subagent set runs a task too wide for one window (`skills/harness/SKILL.md:2-8`, [skills](skills.md)) | [glossary](glossary.md#harness-skill) |
+| the skill's | multi-agent harness selection: which graph workflow or subagent set runs a task too wide for one window (`skills/harness/SKILL.md:11-20`, [skills](skills.md)) | [glossary](glossary.md#harness-skill) |
 
 A claim that says "apply X to the harness" is therefore unreadable until it says
 which. Write **host** for the runtime, **the harness skill** for multi-agent

package/docs/models.md

@@ -22,7 +22,14 @@ generated in every tezgah root because routing needs no capability (`ROLES`,
 `hooks/tezgah_agents.py::ROLES`; their brief, `_worker_body`,
 `hooks/tezgah_agents.py::_worker_body`). So are the five specialists:
 `tezgah-tester`, `tezgah-docs`, `tezgah-security`, `tezgah-ui` and
-`tezgah-researcher` (`hooks/tezgah_agents.py::SPECIALISTS`). A specialist's
+`tezgah-researcher` (`hooks/tezgah_agents.py::SPECIALISTS`). The steering line names the agent per
+task class (`hooks/tezgah_agents.py::STEER`).
+Software design, invariants and unknown-cause debugging go to `tezgah-frontier`.
+A UI, screen or component build or redesign goes to `tezgah-standard`.
+Every tier worker's brief tells a UI build to read the `design-contract` skill, and
+`design-library` for critique (`hooks/tezgah_agents.py::_worker_body`).
+It then derives and checks with `~/.config/tezgah/bin/tezgah-design` before editing.
+Running-app UI or design analysis stays with `tezgah-ui`. A specialist's
 description names its slot from `AGENT_SLOT`. The tier a host shows and the
 model line it runs therefore cannot disagree, and `tezgah-agents --list` prints
 both. A cheaper worker that meets work above its tier answers `ESCALATE: <why>`,
@@ -33,15 +40,31 @@ field or judgement, and only a second miss restarts the task on `tezgah-frontier
 with the original brief rather than handing the failed trajectory up: continuing a
 cheap trajectory on a frontier model was the most expensive option measured
 (arXiv 2608.24358, Table 1: 1.61 cost units against 0.72 for frontier-only).
+A question only the owner can answer climbs past every tier, frontier included.
+It is choosing a variant or option a research, analysis or review recommends, a
+way around a tezgah refusal, or deciding about another session's work. The
+worker answers `ESCALATE: owner` with the options and a recommended default
+(`hooks/tezgah_agents.py::OWNER_ESCALATE`). The orchestrator puts it to the
+user in the approval batch and does not re-brief it.
 
 ## The table (snapshot 2026-09-30)
 
-| slot | agents | anthropic | zai (omp's own provider) | openai | any (OpenRouter id) |
-|---|---|---|---|---|
-| cheap | tezgah-cheap, tezgah-tester | Opus 5.5 @low | `zai/glm-5.3-flash` | GPT-6.1 Sol @low | GLM-5.3 Flash |
-| explore | omp's bundled `scout` | Opus 5.5 @medium | `zai/glm-5.3-flash` | GPT-6.1 Sol @low | DeepSeek V4.1 Flash |
-| standard | tezgah-standard, tezgah-docs, tezgah-ui | Opus 5.5 @medium | `zai/glm-5.3` | GPT-6.1 Sol @high | GPT-6.1 Sol @high |
-| frontier | tezgah-frontier, tezgah-reviewer, tezgah-security, tezgah-researcher | Opus 5.5 @high | `zai/glm-5.3` | GPT-6 Astra @high | Opus 5.5 @high |
+| slot | agents | anthropic | zai (omp's own provider) | openai | any (OpenRouter id) | experientiallabs (models.yml provider) |
+|---|---|---|---|---|---|---|
+| cheap | tezgah-cheap, tezgah-tester | Opus 5.5 @low | `zai/glm-5.3-flash` | GPT-6.1 Sol @low | GLM-5.3 Flash | DeepSeek V4.1 Flash Uncensored @low |
+| explore | omp's bundled `scout` | Opus 5.5 @medium | `zai/glm-5.3-flash` | GPT-6.1 Sol @low | DeepSeek V4.1 Flash | DeepSeek V4.1 Flash Uncensored @low |
+| standard | tezgah-standard, tezgah-docs, tezgah-ui | Opus 5.5 @medium | `zai/glm-5.3` | GPT-6.1 Sol @high | GPT-6.1 Sol @high | DeepSeek V4.1 Flash Uncensored @high |
+| frontier | tezgah-frontier, tezgah-reviewer, tezgah-security, tezgah-researcher | Opus 5.5 @high | `zai/glm-5.3` | GPT-6 Astra @high | Opus 5.5 @high | DeepSeek V4.1 Flash Uncensored @high |
+
+The `experientiallabs` column runs omp through the custom provider of the same
+name in `~/.omp/agent/models.yml` (`OMP_AUTH`, `hooks/tezgah_models.py::OMP_AUTH`).
+omp resolves its key from `~/.omp/.env` as `EXPERIMENTALLABS_API_KEY`.
+The gateway's uncensored DeepSeek V4.1 Flash serves efforts none/low/high/max
+only (gateway model metadata, read 2026-10-20). Cheap and explore therefore
+carry `low` where the Anthropic column carries `medium`. The column has no
+`SNAPSHOT` row: `SNAPSHOT` holds OpenRouter ids, and `refresh` compares against
+OpenRouter's list. The provider's prices live in the models.yml `cost` block
+instead.
 
 Why these, briefly. Inside the Anthropic family the lever is effort, not model:
 Opus 5.5 and Sonnet 5.5 read cache at the same $0.20 per 1M tokens, and on
@@ -64,7 +87,7 @@ invoices).
 | Claude Code | anthropic | the agent file's alias and `effort:` (`_model_lines`): an alias follows the provider and keeps the main session's variant, where a full id breaks on Bedrock, Vertex and a gateway (code.claude.com/docs/en/sub-agents) |
 | Codex | openai | `model` and `model_reasoning_effort` in `$CODEX_HOME/agents/*.toml` |
 | opencode | any | a selector `--refresh` found in `opencode models` for the slot's model under any configured provider (`resolve_opencode`); none found, no model line, so the agent inherits. The slot's effort rides the JSON agent config as `reasoningEffort` (opencode.ai/docs/agents) |
-| omp | anthropic when the session default is an Anthropic model, any otherwise (`omp_mode`); a non-Anthropic default is `any`, never a silent fall back to the Anthropic column | `task.agentModelOverrides`, which omp resolves before the agent or bundled model (omp's own docs: `omp://task-agent-discovery.md`, *Model and structured-output precedence*); every slot is written, the frontier row included, so no agent in the row runs on the session default; each override is a **fallback chain** (`omp_overrides`, `_chain`): the mode's family first, then what `fallback` in `~/.config/tezgah/config.json` allows (`tp.fallback_policy`) over the families this machine holds a credential for (`funded_families` reads omp's auth store and the provider env keys; a family it cannot see is left out, never guessed in) - `vendor`, the default, keeps only the session vendor's model (`openrouter/anthropic/claude-opus-5.5:<effort>` behind an Anthropic session, `OPENROUTER_ID`), so a 429 never moves an Opus session's subagent onto GPT or GLM; `any` adds every other funded family, rotated per agent; `none` writes the first entry alone - omp splits the chain into per-spawn patterns (omp's own docs: `omp://settings.md (its `retry.fallbackChains` section)`), so one provider's 429 falls through instead of killing the spawn, measured before this: 24 of 26 post-routing 429s hit a subagent's first request, all on one Opus account every slot shared; `apply_omp` also writes `modelRoles.plan` and `.slow` on that frontier row (same record, same ownership) so plan mode designs on it, and their fallbacks go to `retry.fallbackChains.<role>` under the same `fallback` rule, the only chain keys tezgah owns (`default` and provider-keyed chains stay the user's); `apply_omp` writes through the installer's own binary and agent dir, from HOME so a repository's `.omp/config.yml` never leaks machine-wide, and touches only the entries tezgah wrote (recorded in `~/.config/tezgah/models.json` as `omp_written`; a machine written before that record is adopted by its value, `_ours_by_shape`); a changed `fallback` reaches omp on the next `tezgah-route --refresh` or `tezgah-setup --install` |
+| omp | the saved `--mode` family, else anthropic when the session default is an Anthropic model, `experientiallabs` when it is an `experientiallabs/` selector, `any` otherwise (`omp_mode`); a non-Anthropic default is `any`, never a silent fall back to the Anthropic column | `task.agentModelOverrides`, which omp resolves before the agent or bundled model (omp's own docs: `omp://task-agent-discovery.md`, *Model and structured-output precedence*); every slot is written, the frontier row included, so no agent in the row runs on the session default; each override is a **fallback chain** (`omp_overrides`, `_chain`): the mode's family first, then what `fallback` in `~/.config/tezgah/config.json` allows (`tp.fallback_policy`) over the families this machine holds a credential for (`funded_families` reads omp's auth store and the provider env keys; a family it cannot see is left out, never guessed in) - `vendor`, the default, keeps only the session vendor's model (`openrouter/anthropic/claude-opus-5.5:<effort>` behind an Anthropic session, `OPENROUTER_ID`), so a 429 never moves an Opus session's subagent onto GPT or GLM; `any` adds every other funded family, rotated per agent; `none` writes the first entry alone - omp splits the chain into per-spawn patterns (omp's own docs: `omp://settings.md (its `retry.fallbackChains` section)`), so one provider's 429 falls through instead of killing the spawn, measured before this: 24 of 26 post-routing 429s hit a subagent's first request, all on one Opus account every slot shared; `apply_omp` also writes `modelRoles.plan` and `.slow` on that frontier row (same record, same ownership) so plan mode designs on it, and their fallbacks go to `retry.fallbackChains.<role>` under the same `fallback` rule, the only chain keys tezgah owns (`default` and provider-keyed chains stay the user's); `apply_omp` writes through the installer's own binary and agent dir, from HOME so a repository's `.omp/config.yml` never leaks machine-wide, and touches only the entries tezgah wrote (recorded in `~/.config/tezgah/models.json` as `omp_written`; a machine written before that record is adopted by its value, `_ours_by_shape`); a changed `fallback` reaches omp on the next `tezgah-route --refresh` or `tezgah-setup --install` |
 | dsh | - | none: no model setting was found to write |
 
 The orchestrator agent keeps `model: inherit`: it is the main thread's own agent.
@@ -215,7 +238,7 @@ moved against the snapshot (`SNAPSHOT`, `hooks/tezgah_models.py::SNAPSHOT`;
 re-applies omp's overrides. Scores are not re-read - they need a key - so
 `tezgah-route --check` reports the snapshot's age and exits 1 past 60 days or with
 a flag (`check`, `hooks/tezgah_models.py::check`); that is the moment to re-read
-the leaderboards and edit `SLOTS`. `tezgah-route --mode anthropic|zai|any|openai|auto|off` pins
+the leaderboards and edit `SLOTS`. `tezgah-route --mode anthropic|zai|any|experientiallabs|openai|auto|off` pins
 omp's family instead of following the session default; `off` removes every entry
 and role the table wrote and writes nothing, which is the way back when the
 provider those selectors need has no budget - a measured case, not a
@@ -229,6 +252,11 @@ omp status report carries a row for them.
 login (`OMP_OPENAI`, `hooks/tezgah_models.py::OMP_OPENAI`). Its ids are not the
 Codex host's `openai` column, which omp does not list. The mode is never a
 fallback for the others, and with no `openai-codex` login it writes nothing.
+`experientiallabs` pins the custom models.yml provider of the same name
+(`FAMILY_PREFIX`, `hooks/tezgah_models.py::FAMILY_PREFIX`). The selector is
+`experientiallabs/<model id>`, and omp reads its key from `~/.omp/.env`. The
+mode therefore applies even where that env var is not exported to the shell
+tezgah runs in.
 
 ## Source of truth
 

package/docs/operations.md

@@ -19,8 +19,8 @@ before an install is considered.
 | `--install` | Arm the `--hosts` (default: every detected host): writes `~/.config/tezgah/config.json`, the contract hash, the `~/.config/tezgah/bin` symlinks and every host file, then prints the report. Installs the missing optional tools first unless `--no-deps`; third-party host CLIs (cursor-agent, pnpm, dsh) only with `--host-deps`, otherwise their exact install command is printed. Exits 1 when a requested tool is still missing, naming the cause (`installer failed with exit N`, or `exited 0 but not on PATH`) (`bin/tezgah-setup::main`, `bin/tezgah-setup::install_all`, `bin/tezgah-setup::install_deps`). It also exits 1 when a planned host is left unarmed, and names it under `not armed:`. Only the arming rows count: hooks wired, the contract current, and the row a host's own CLI arms where that CLI exists: omp's extension row with an omp CLI, Claude's `plugin copy current` with a `claude` CLI. Codex `hooks trusted` and the provider-key rows stay out, because a correct fresh install leaves them MISS (`ARMING_ROWS`, `arming_miss()`). A host config that does not parse as a JSON object is refused: the run names the file and the parse error, never writes it, and exits 1 (`read_config()`); tezgah's own `config.json` is refused the same way. Claude is registered through its own CLI (`register_claude_plugin()`): the run renders `.claude-plugin/{plugin,marketplace}.json` from the release version into the tree it runs from (untracked; a pair under another marketplace name is kept), runs `claude plugin marketplace add <tree>` (a directory source pinned to that tree) and `claude plugin install tezgah@tezgah-local`, and skips both when any `tezgah@*` row is already in `installed_plugins.json`, because a second row fires every hook twice. `--reply-lang tr|en|any` stores `reply_lang` in `config.json`; without it the stored value stays, and a config with none reads as `tr`. |
 | `--wizard` | Ask the install questions and write only after the final yes; the other flags supply the defaults, so `--wizard --hosts omp` asks only the rest (`bin/tezgah-setup::wizard`). |
 | `--report` | Print what is armed, per host, and stop (`bin/tezgah-setup::main`, `bin/tezgah-setup::report`). |
-| `--report --live` | Proves the hooks run, not only that they are written (audit Phase 1.2). For each host, one synthetic PostToolUse (`true`) goes through that host's own wiring: the command in `~/.codex/hooks.json`, `~/.cursor/hooks.json`, the enabled Claude plugin copy's `hooks/hooks.json` (with `CLAUDE_PLUGIN_ROOT`), the hooks.json named by dsh's `cordis.patch.yml`; the opencode plugin is imported with node the way opencode imports it; the omp extension `.ts` is loaded with node `--experimental-strip-types` after checking it is in omp's `extensions` list. A ledger row for a dedicated `tezgah-live-<pid>-<ms>` session must appear; the event runs against a throwaway root (`TEZGAH_ROOTS`) and every cache file named for that session is deleted afterwards. A second probe per host proves the gate: one PreToolUse for `git commit --no-verify -m x` through the same wiring must come back as that host's deny (Claude, Codex and dsh `permissionDecision: deny`, Cursor `permission: deny`, omp `block: true`, opencode a throw) and leave a `deny` row in the ledger; under `pretooluse-off` or `verify-off` it reads UNVERIFIED and names the switch (`live_probe()`, `LIVE_DENY_COMMAND`). The omp bridge must also match a fresh render byte for byte, from the renderer the install writes with (`omp_bridge()`). Rows read `ok live <host>` / `ok live <host> deny`, `MISS live <host>: <cause>` (no tezgah command in the host file, the command wrote no row, no deny envelope or no deny row, a hand-edited omp bridge, Codex does not trust tezgah's group) or `UNVERIFIED live <host>: <why>` (node missing or older than 22.6, the omp CLI did not answer, a switch that stands the refusal down). It exits 1 when any host is MISS; UNVERIFIED never fails the run and is never shown as ok. No model is called. |
-| `--refresh` | Re-render every always-on contract artifact of the armed hosts - the managed blocks of `CLAUDE.md`, Codex's `AGENTS.md` and omp's `RULES.md`, opencode's contract and skill routers - after a policy edit or a kill switch; prints the paths it refreshed, else `contract is current`. Before the first install there is no hash record, so it changes nothing (`refresh_contract`, `bin/tezgah-setup::refresh_contract`). |
+| `--report --live` | Proves the hooks run, not only that they are written (audit Phase 1.2). For each host, one synthetic PostToolUse (`true`) goes through that host's own wiring: the command in `~/.codex/hooks.json`, `~/.cursor/hooks.json`, `~/.qwen/settings.json` (a `run_shell_command` payload), `~/.factory/hooks.json` (an `Execute` payload), `~/.commandcode/settings.json` (a `shell_command` payload), `$COPILOT_HOME/hooks/tezgah.json` (a `Bash` payload), `~/.gemini/extensions/tezgah/hooks/hooks.json` (a `run_shell_command` payload), the `tezgah` name of `~/.gemini/config/hooks.json` (a camelCase `run_command` payload, the event on the command line), `~/.agents/plugins/tezgah/hooks/hooks.json` (a `shell` payload, the event in `event`), the enabled Claude plugin copy's `hooks/hooks.json` (with `CLAUDE_PLUGIN_ROOT`), the hooks.json named by dsh's `cordis.patch.yml`; the opencode plugin is imported with node the way opencode imports it; the omp extension `.ts` is loaded with node `--experimental-strip-types` after checking it is in omp's `extensions` list; Amp's plugin `tezgah.ts` is loaded the same way and fed Amp's own `tool.call`/`tool.result` events (a `Bash` call carrying `cmd`). A ledger row for a dedicated `tezgah-live-<pid>-<ms>` session must appear; the event runs against a throwaway root (`TEZGAH_ROOTS`) and every cache file named for that session is deleted afterwards. A second probe per host proves the gate: one PreToolUse for `git commit --no-verify -m x` through the same wiring must come back as that host's deny (Claude, Codex, dsh, Qwen, Droid and Command Code `permissionDecision: deny` under `hookSpecificOutput`, Copilot the same at the top level, Gemini and Antigravity a top-level `decision: deny`, Goose a top-level `decision: block`, Cursor `permission: deny`, omp `block: true`, Amp `action: reject-and-continue`, opencode a throw) and leave a `deny` row in the ledger; under `pretooluse-off` or `verify-off` it reads UNVERIFIED and names the switch (`live_probe()`, `LIVE_DENY_COMMAND`). The omp bridge and the Amp plugin must also match a fresh render byte for byte, from the renderer the install writes with (`omp_bridge()`, `hooks/tezgah_attest.py::amp_plugin`). Rows read `ok live <host>` / `ok live <host> deny`, `MISS live <host>: <cause>` (no tezgah command in the host file, the command wrote no row, no deny envelope or no deny row, a hand-edited omp bridge or Amp plugin, Codex does not trust tezgah's group) or `UNVERIFIED live <host>: <why>` (node missing or older than 22.6, the omp CLI did not answer, a switch that stands the refusal down, and always for Amp, whose own Bun loader is not what ran the plugin). It exits 1 when any host is MISS; UNVERIFIED never fails the run and is never shown as ok. No model is called, so the probe proves the hook command, not that the host binary obeys it: for Qwen that is `TEZGAH_E2E_SPEND=1 python3 tests/e2e_qwen.py` and for Droid `TEZGAH_E2E_SPEND=1 python3 tests/e2e_droid.py`, each spending a model call; Command Code, Copilot, Gemini, Antigravity, Goose and Amp have no such script yet, so their obedience is unverified. |
+| `--refresh` | Re-render every always-on contract artifact of the armed hosts - the managed blocks of `CLAUDE.md`, Codex's `AGENTS.md`, omp's `RULES.md`, Qwen's `QWEN.md`, Droid's, Command Code's and Amp's `AGENTS.md`, Copilot's `copilot-instructions.md`, the `GEMINI.md` Gemini and Antigravity share, Goose's `.goosehints`, opencode's contract and skill routers - after a policy edit or a kill switch; prints the paths it refreshed, else `contract is current`. Before the first install there is no hash record, so it changes nothing (`refresh_contract`, `bin/tezgah-setup::refresh_contract`). |
 | `--uninstall` | Remove everything tezgah installed — per host the wiring it wrote, plus (a full run) the Claude plugin copy with its registry rows, the generated config state, the kill switches, the caches and the versioned install tree — then verify the removal; nonzero exit while anything tezgah wrote survives (`bin/tezgah-setup::verify_uninstall`, `bin/tezgah-setup::uninstall`). |
 | `--adopt` | Move pre-tezgah wiring aside instead of deleting it; alone it stops there, with `--install` it runs first (`bin/tezgah-setup::main`, `bin/tezgah-setup::adopt`). |
 | `--sync` | Copy this checkout over the Claude plugin [copy](glossary.md#plugin-copy) `installed_plugins.json` names, or over every copy when it names none (`bin/tezgah-setup::sync`, `bin/tezgah-setup::live_plugin_copies`). An older version dir is Claude's cache to collect, so it is left alone. Each copy is built in a staging tree beside the plugin cache and swapped in with two renames, its `.git` carried over, so a failed or killed sync leaves the previous copy whole (`bin/tezgah-setup::_swap`). Every copied file is 0644, or 0755 when the tree marks it executable, whatever mode the source has (`bin/tezgah-setup::_copy_normalised`). |
@@ -41,7 +41,7 @@ before an install is considered.
 | `update` | `tezgah update [--dry-run]` moves this install to the newest release through the channel it came from, then re-arms the hosts from the new tree. A release prefix goes through `--upgrade`. A Homebrew keg runs `brew upgrade r1z4x/tezgah/tezgah`, an npm tree runs `npm install -g @r1z4x/tezgah@latest`, and a git checkout runs `git pull --ff-only` (`update()`, `hooks/tezgah_update.py`). Before re-arming it prints every tezgah hook entry the new tree adds, removes or changes, per host. Paths compare with the tree root taken out, so a move to the new release's own path is no change. A real change on a terminal waits for a yes; Enter is no. A piped run goes on without asking (decision 12; `hooks/tezgah_update.py::confirm_rearm`). A no exits 1 after the fetch and says what it left. A checkout or an npm package is replaced in place, and the prefix's `current` already points at the new tree, so there the hooks run the new code and only the changed entries wait. A Homebrew keg is new beside the old one, so hooks wired to the old keg's path run the old code until the re-arm (`NOT_REARMED`, `hooks/tezgah_update.py::NOT_REARMED`). |
 | `--version` | Print the plugin version and exit (`bin/tezgah-setup::main`, `hooks/tezgah_context.py::version`). |
 | `--roots R` | Set the roots for this install, `os.pathsep`-separated. Without `--install` it exits 1: `--roots only means something with --install` (`bin/tezgah-setup::main`). |
-| `--hosts H` | Comma-separated subset of `claude,codex,opencode,cursor,dsh,omp`; an unknown name exits 1 before anything is written, and naming hosts switches off the re-detection that follows a tool install (`bin/tezgah-setup::main`, `bin/tezgah-setup::install_all`). |
+| `--hosts H` | Comma-separated subset of `claude,codex,opencode,cursor,dsh,omp,qwen,droid,commandcode,copilot,gemini,antigravity,goose,amp`; an unknown name exits 1 before anything is written, and naming hosts switches off the re-detection that follows a tool install (`bin/tezgah-setup::main`, `bin/tezgah-setup::install_all`). `--install --hosts X` adds X to the hosts recorded in `config.json` and keeps the others. |
 | `-h`, `--help` | Usage and the list above (`bin/tezgah-setup::main`). |
 
 A green `--report` says the wiring is on disk; `--report --live` says it ran. What it cannot cover is the host binary itself: it runs the command the host would run, not the host, so a host that refuses to load its own config (a Claude plugin disabled in the UI after the check, a dsh build whose bridge drops the event) still needs a real session to show.
@@ -186,7 +186,7 @@ too, from the same `hosts_row`, so the mismatch reaches the surface a session
 checks its own health with. Two places deliberately do not: the status line's
 marks are the armed/used checklist and are redrawn by a fresh process on every
 host (omp re-renders per tool result), while "wired" is `HOST_CHECKS`, the
-installer's own reading of six host files — a second reading of it in `hooks/`
+installer's own reading of eight host files — a second reading of it in `hooks/`
 would be the drift `AGENTS.md` names as the report's source of truth; and
 `bin/tezgah-doctor` accounts for the bytes the hosts' stores hold and never reads
 a host's config, so a wiring row there would belong to a different tool.
@@ -233,7 +233,7 @@ After a change to the contract text (`hooks/tezgah_policy.py`,
 - `--install` re-renders every host file, the opencode contract and the skill
   router, and rewrites `~/.config/tezgah/contract.sha256`, which holds one
   `<sha>  <path>` line per rendered artifact - the managed blocks of
-  `CLAUDE.md`, `AGENTS.md` and `RULES.md`, `opencode-contract.md` and the
+  `CLAUDE.md`, Codex's, Droid's, Command Code's and Amp's `AGENTS.md`, `RULES.md`, `QWEN.md`, `copilot-instructions.md`, `GEMINI.md` and `.goosehints`, `opencode-contract.md` and the
   `opencode-skills*.md` routers - rather than one hash over the sources
   (`bin/tezgah-setup::record_shas`, `bin/tezgah-setup::contract_artifacts`).
 - `--refresh` does that without a reinstall, for every armed host's static
@@ -401,6 +401,19 @@ extension the engine has no parser for and an extensionless script it cannot key
 on at all. The extensionless case is why `bin/*` carries `.py` twins, and the
 report counts a tracked `bin/x` as covered when the index holds `bin/x.py`.
 
+A linked worktree starts with its main checkout's index. Git ignores
+`.codegraph/`, so a new worktree has none. When the main checkout has one, the
+auto-index copies it into the worktree before it starts the worker
+(`hooks/tezgah_context.py::seed_index`, called from
+`hooks/tezgah_context.py::autoindex`). The copy uses sqlite's backup API. The
+worker then runs `codegraph sync`, not `init` (`hooks/tezgah_index.py::command`).
+The database stores repo-relative paths, so the synced copy reads the
+worktree's own files. On this
+repository a sync over the copy took 1 s, and a fresh `init` took 10 s.
+`tezgah-task start` run inside a worktree seeds and starts the index the same
+way (`bin/tezgah-task::cmd_start`). A copy that fails leaves the worktree to
+`init`, as before.
+
 ## Opt-in taste: capture, learn, apply
 
 Taste learns the user's coding preferences from their own corrections. It is
@@ -631,6 +644,103 @@ it costs nothing there. On held-out Turkish phrasings of the docs index,
 meaning alone found the page in the top three for 0.91 with `embed-mrl` and 0.78
 with `embed-m2v`. The fusion found it for 0.75 and 0.74, BM25 for 0.68.
 
+## Opt-in OCR review spec: `ocr`
+
+The `ocr` feature id adds open-code-review (OCR) to a plan's review. It is off by
+default (`"default": False` in `hooks/tezgah_apps.py::REGISTRY`). Turn it on with
+`tezgah-setup --enable ocr`, which runs
+`npm install -g @alibaba-group/open-code-review@1.13.2`, the release whose prompts,
+delegate and rules match the vendored 375f64c texts. The binary is
+found by `ocr_bin()` (`hooks/tezgah_paths.py::ocr_bin`): `TEZGAH_OCR_BIN` first,
+then `ocr` on PATH. The verification step uses it only while `features` in
+config.json lists `ocr`, so an `ocr` installed for other
+work changes nothing. The report prints one `ocr on PATH` row
+(`bin/tezgah-setup::report`). Without `ocr` nothing changes: the verification
+step prints the same lines as before.
+
+With `ocr` installed, round one of the verification step adds an OCR review spec
+(`bin/tezgah-task::print_ocr_spec`). It runs `ocr delegate preview` and
+`ocr delegate rule` over `<base>..HEAD`. Both are deterministic and call no model
+(`bin/tezgah-task::ocr_spec`). The spec is input to the review, never a verdict.
+A failed or timed-out call prints one `OCR spec skipped:` line and the step
+goes on without it (`bin/tezgah-task::ocr_json`).
+
+The spec prints these lines:
+
+- The reviewable files OCR selected.
+- The files OCR excluded, with OCR's reason. OCR excludes tests and `.md` files.
+  They stay in the reviewer's scope: one more tezgah-reviewer reads them over the
+  usual dimensions.
+- The reviewer split, which follows OCR's own bundling thresholds. Under 4 files
+  and under 200 changed lines, one reviewer reads the whole change set. Under 4
+  files, one reviewer reads each file. From 4 files, one reviewer reads each OCR
+  rule group. Each brief carries its group's rule text verbatim and names the
+  vendored `main_task_system.md` as an appendix (`bin/tezgah-task::OCR_PROMPTS`).
+  Without a rule group, the per-dimension fan-out stands.
+- The refuter pass. Once the review merges its findings, one fresh tezgah-reviewer reads
+  the vendored `review_filter_task_system.md` as its instructions. It removes
+  only findings the diff proves wrong.
+- The quote check, `tezgah-review-quote` over the merged findings.
+
+The reviewer brief carries the matching rule
+(`hooks/tezgah_agents.py::_reviewer_body`). A reviewer given an OCR rule group
+accounts for every listed file as reviewed or skipped with a reason. It still
+applies the rest of its brief.
+
+The reviewer also has a plan-readiness mode for a plan file instead of a diff
+(`hooks/tezgah_agents.py::_reviewer_body`). It restates each section's intent in
+one sentence. A section it cannot restate is a major finding. A build choice the
+plan leaves to the implementer is a major finding too. A file the plan will
+create is not a missing reference. `skills/plan-add/SKILL.md` runs this review
+once before the `implementation` phase.
+
+`tezgah-review-quote --from BASE [--to HEAD] FINDINGS.json` places each finding by
+its quoted code (`bin/tezgah-review-quote::main`). Each finding needs `path` and
+`quote`, and may carry the `start_line` it cites. The tool adds a `status`.
+`located` means the quote is in the finding's own file. The match covering the
+cited line wins, else the one new-side match, else the one match. `unlocated`
+with `reason: "ambiguous: N matches"` means several matches and no cited line
+among them. `relocated` means no match in its own file and exactly one in
+another changed file, and `path` moves there. Any other `unlocated` finding goes
+back to its reviewer. A placed finding gets `start_line` and `end_line`, and
+`side: "old"` when the lines are pre-change (`bin/tezgah-review-quote::resolve`).
+It ports OCR's comment positioning from `internal/diff/resolver.go`.
+
+`tezgah-ocr-review [--from REF --to REF | --commit SHA] [--model SELECTOR]
+[--output FILE] [--allow-secrets]` runs OCR's own review loop on omp only. It
+starts one `omp auth-gateway stdio` child (`bin/tezgah-ocr-review::Gateway`).
+OCR then reviews on omp's model with omp's own credentials.
+
+- A loopback HTTP shim forwards OCR's requests to that child
+  (`bin/tezgah-ocr-review::handler`). It accepts `POST /v1/chat/completions` and
+  `GET /v1/models` only, with the per-run bearer token the tool hands OCR.
+  Another local process cannot spend omp's credentials during a run.
+- The tool writes no OCR provider config. OCR runs with a private, empty `HOME`.
+  A `~/.opencodereview/config.json` from standalone OCR use cannot redirect the
+  review.
+- Only the OCR process loses the caller's `OCR_*`, `ANTHROPIC_*` and `OPENAI_*`
+  variables (`bin/tezgah-ocr-review::run`). Git under OCR keeps the user's
+  global config and excludes, so a globally ignored file stays ignored. The omp
+  child keeps the caller's environment, because it needs omp's own credentials.
+- A path that looks like a secret stops the run with exit 3
+  (`bin/tezgah-ocr-review::first_secret`). In workspace mode the check covers
+  tracked, untracked and ignored files. In range or commit mode it covers the
+  tree of the reviewed ref. `--allow-secrets` skips the check. The patterns are
+  OCR's own (`bin/tezgah-ocr-review::SECRET_PATTERNS`).
+- A missing `ocr` or `omp` exits 2. A setup failure of the tool itself exits 4
+  with one line (`bin/tezgah-ocr-review::SetupError`). Three failures count:
+  no git repository, omp cannot start, the gateway never reports ready.
+
+Its findings are candidates for a tezgah-reviewer, never a verdict.
+
+`tezgah-setup` links both CLIs into `~/.config/tezgah/bin`
+(`bin/tezgah-setup::install_common`).
+
+The two OCR prompts live under `third_party/open-code-review/`. Tezgah copies them
+verbatim from alibaba/open-code-review at commit `375f64c`, under the Apache
+License 2.0, with its `LICENSE` beside them. Each prompt has one added first
+line, the modification notice (`third_party/open-code-review/README.md`).
+
 ## Plan records: the lock, `landed`, the close commit
 
 Every `tezgah-task` writer of a plan record holds an exclusive lock on the
@@ -746,6 +856,10 @@ that was active when it opened, and only that plan's records count. A record
 with no plan counts when it changed after the plan's checkpoint commit. A
 `resumed` record hands the guard to its re-dispatch's own record
 (`bin/tezgah-task::unfinished_review`).
+`tezgah-task review` also refuses an approve with no record of that reviewer for the plan. A
+reviewer with no status did not run. A host that keeps no slice journal passes
+`--no-slice "<why>"`, and the plan's `review:` line keeps that reason
+(`bin/tezgah-task::cmd_review`). A `changes` verdict needs no record.
 The lever map is a closed set. `rate_limit` and `quota` point at the
 `hooks/tezgah_models.py` fallback chain. `cut_off` and `timeout` point at a
 per-slice deadline, `aborted` at the `wip:` commit cadence, a duplicate job at
@@ -761,6 +875,24 @@ The `~/.config/tezgah/slices-off` switch
 stops the hooks from writing records (`hooks/tezgah_paths.py::UNCLASSIFIED_SWITCHES`).
 A cwd outside a git repository writes nothing either.
 
+## A repository that is not this harness's
+
+Tezgah arms every repository under a root, because `roots()` is the only switch
+that decides. Every other switch is global (`~/.config/tezgah/*.off`) or
+per-feature (`.no-ponytail`, `.no-graph`). A project whose workspace is not this
+harness's says so itself, in a `tezgah.owner` file it commits at its own top:
+
+| Setting | What stops |
+|---|---|
+| `tasks: off` | the plan and task machine: no active task (`hooks/tezgah_task.py::_phased`), so no per-turn phase line and no scope held to a plan, the record rule holds no write to its own plan files (`hooks/tezgah_task.py::phased_record`), and every `tezgah-task` command that writes a record - the plan writers, the slice journal and `sweep` - is refused with the file named (`bin/tezgah-task::writes_a_record`, `bin/tezgah-task::owner_mark`). The scope gate, `bin/run-tool`, research and lessons keep reading the repository |
+| `harness: excluded` | everything: `root_for` answers None, so no contract text is injected, no workspace is set up, no plan, task or lesson record is written, and the gate passes every call (`hooks/tezgah_paths.py::harness_excluded`) |
+| `owner: <name>` | nothing - it names who owns the workspace, for the person reading the diff |
+
+The file comes from the nearest `.git` top at or above the path, so a repository
+cloned inside a marked one answers for itself. A missing or unreadable file, an
+unknown key and a blank value decide nothing
+(`hooks/tezgah_paths.py::owner_marker`).
+
 ## Troubleshooting
 
 | Symptom | First check | Likely cause |
@@ -911,6 +1043,10 @@ page exits 1 with the message it always printed (`available()`,
   spawn parser, reconcile, resume, prune and stats.
 - `hooks/tezgah_paths.py`, `hooks/tezgah_context.py` — the paths and `off()`; the
   marks and the kill-switch filtering.
+- `bin/tezgah-task`, `bin/tezgah-review-quote`, `bin/tezgah-ocr-review`,
+  `third_party/open-code-review/` — the opt-in OCR review spec, the quote check,
+  OCR's own loop on omp, and the vendored prompts. `tests/test_task.py`,
+  `tests/test_review_quote.py` and `tests/test_ocr_review.py` pin them.
 - `RELEASING.md`, `README.md`, `AGENTS.md`, `.gitignore`, `tests/test_setup.py` —
   the version rule, the install and configuration sections, the layer map, what
   stays untracked, and the behaviour these checks pin.