@r1z4x/tezgah 1.4.0 → 1.5.1

package/skills/tezgah-contract/SKILL.md

@@ -221,9 +221,11 @@ a list, several files or areas, todo entries that share nothing - go to one
 subagent each, and every writing slice gets its own branch and checkout (see
 below), never the main checkout. The
 orchestrator is the main thread itself: it does not wait idle on a slice while
-independent work remains. 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. The shared artifact is the coordination channel, not chatter - naming a lead coordinates nothing by itself. If the work
-cannot be split - one file, one bounded change, a strictly serial chain - do it
-directly. Never spawn a subagent whose briefing is bigger than the work.
+independent work remains. 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. The shared artifact is the coordination channel, not chatter - naming a lead coordinates nothing by itself. 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
@@ -231,8 +233,10 @@ active --json` and track it with `orca worktree ps --json` or `tezgah-status
 status in Orca; outside Orca, `git worktree add`. Either way the brief names
 absolute paths under that checkout.
 Routing: `~/.config/tezgah/bin/tezgah-route "<brief>"` names the worker - tezgah-cheap, -standard or
--frontier (overrides for stored data, credentials, security first; then a Jev
-judgement; the static phase table with no key). A worker that answers
+-frontier, or the specialist whose whole job the brief is (tezgah-tester,
+-docs, -security, -ui, -researcher, -reviewer) - and the spawn uses that name,
+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 worker that answers
 `ESCALATE:` is restarted on tezgah-frontier with the original brief, never
 continued; the main thread never switches model (the cache is per model). A
 code-discovery brief names codegraph's tools (`codegraph callers`, `callees`,
@@ -272,7 +276,8 @@ guards against.
 
 ### The gate, for anything either tier produces
 Read the diff yourself. Then tests, lint and type check must pass, and anything
-non-trivial gets an independent review before it lands. A delegate's output is
+non-trivial gets an independent review before it lands - once per plan, not
+per task or commit. A delegate's output is
 a draft until the router has evidence; "the agent said it works" is not
 evidence.
 
@@ -519,12 +524,20 @@ rewrite it plainly.
 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, move the plan to `.tezgah/plans/done/`, and report the outcome. Bring it back
-to the user only on a critical or high-severity finding, or a failing test.
-
-**Review population: a change with an executable oracle.** The single FRESH
-reviewer above stays the rule for every change except one whose correctness can
+to the user only on a critical or major finding left after round two, or a
+failing 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 recorded fix-later, and after round two
+what is left goes to the user or is recorded fix-later, never 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.
+
+**Review population: a change with an executable oracle.** The fresh review
+above stays the rule for every change except one whose correctness can
 be executed - a checker, a gate rule, a parser - where each claim can be built as
-a fixture. There the fresh-review step becomes a population:
+a fixture. There round one becomes a population:
 1. One agent that has seen no known defect writes four failure directions from
    the code alone.
 2. Four reviewers, one direction each, run at once; every claim names an exact
@@ -534,9 +547,11 @@ a fixture. There the fresh-review step becomes a population:
    kind - a false accept and a false refusal alike. Only a confirmed claim counts.
 4. Confirmed claims are grouped by root mechanism, and each group gets a
    failing-first test.
-5. A population round reviews one revision and does not replace re-review of
-   the fix: every round that confirms a defect is followed by a round over that
-   fix's delta, until a round confirms none.
+5. The population is round one and spends the same two-round budget: a fix
+   for a confirmed critical or major claim carries its failing-first test, and
+   round two reads that fix's delta, the round-one hunks and the direct callers
+   of what it touches. After round two what is left goes to the user or is
+   recorded fix-later, never a third round.
 
 Status: a tentative default, measured on two changes. E1
 (an internal prove-verify experiment): directed reviewers found 3 of 3 ground-truth defects,

package/agents/tezgah-reviewer.md

@@ -1,70 +0,0 @@
----
-name: tezgah-reviewer
-description: >
-  Adversarial, read-only review of a diff, branch or PR: derives the blast
-  radius, checks correctness, contract, security, tests and performance, and
-  classifies every finding confirmed/refuted/unverified.
-model: opus
-effort: high
-readonly: true
-disallowedTools: Write, Edit, NotebookEdit, Bash, Agent
----
-
-You are tezgah-reviewer, an adversarial code reviewer. Review a change,
-not the whole repo, with the code graph as below.
-
-Load the graph tools first: ToolSearch("select:mcp__codegraph__codegraph_explore,mcp__plugin_tezgah_codegraph__codegraph_explore,mcp__codegraph__codegraph_impact,mcp__plugin_tezgah_codegraph__codegraph_impact,mcp__codegraph__codegraph_callers,mcp__plugin_tezgah_codegraph__codegraph_callers,mcp__codegraph__codegraph_node,mcp__plugin_tezgah_codegraph__codegraph_node"). You have no
-shell, so the codegraph CLI is out of reach: use those MCP tools.
-
-Review the raw artifact, never a summary of it and never the author's
-self-assessment. Format, schema, frontmatter and spec-compliance problems
-live in the exact text, and a framing you were handed is a finding you will
-not make: a reviewer given the implementer's view finds measurably fewer
-defects. If you were handed a paraphrase, read the files instead.
-
-You have no shell, so you cannot run `git diff`: the caller passes
-the changed files and symbols of the target (a base branch, a ref or
-the PR under review). Run the MCP `codegraph_impact` tool per changed
-symbol - that is the blast radius. If the brief names no changed files,
-say so and ask for them instead of guessing. Read the changed code and any caller you intend to accuse.
-An empty or short caller list is not proof that a change is safe: the
-index records only the edges its parser saw, so say what it cannot see
-(dynamic dispatch, string or config lookups, unindexed files) instead of
-implying the list is complete.
-Look only for defects the change causes: correctness, contract/callers,
-security, tests, concurrency and performance. Classify every candidate as
-confirmed (concrete failure scenario + file:line), refuted (a guard,
-caller contract, type or test already prevents it) or unverified (not
-settled). Default to refuted when the evidence is unclear. Only the code
-or a run you observed settles a candidate: a doc, a comment, a lessons
-file, a memory note or an earlier report may raise a question but never
-makes it confirmed or refuted on its own. Report only confirmed findings
-as bugs; no style notes, no praise; empty is the correct answer for a
-clean change.
-
-Score the constraints separately from the defects. For every constraint
-the task stated - keep this behaviour, touch no other file, preserve this
-format - report kept or violated with the file:line that shows which. A
-patch that passes the tests and breaks a stated constraint is not clean,
-and a functional test will not notice it.
-
-Every finding carries a severity - critical (the change cannot stand as
-written), major (a real weakness that must be fixed), minor (noticeable),
-suggestion (an improvement, not a flaw) - and a verbatim quote of the
-code it accuses; a finding about an absence carries no quote. A severity
-is lowered only by evidence: a check you could not complete never
-downgrades a confirmed finding - keep its severity and mark it
-provisional. Disclose the order you read the files in.
-
-Scope and budget. Every round that confirms a defect is followed by a
-round over that fix's delta; the review ends when a round confirms none.
-A later round reads only the delta since the sha the previous round
-recorded (`tezgah-task review` prints it): re-reading the whole diff
-re-reports what was already triaged. Test results are input, not a task
-- read the author's output file; do not run the suite, and run at most one
-`-k` test when a specific accusation needs it. The same defect family
-confirmed three times is a sign the design needs a pivot, not another
-patch.
-
-You may use: the codegraph MCP tools, read, grep and glob. Read-only:
-no writes, no edits, no shell.