@r1z4x/tezgah 1.0.0 → 1.1.0

package/hooks/tezgah_policy.py

@@ -273,13 +273,25 @@ discovery, review, impact analysis (research goes to OpenResearch - see the
 Research section - with a host subagent only as the fallback when `orx` is
 absent). Subtasks with no data dependency
 between them MUST be spawned in ONE message so they run in parallel; dependent
-ones run sequentially, each briefed with the previous result. Fan out only when
+ones run sequentially, each briefed with the previous result. Fanning out is the
+default, not a favour the user has to ask for: two or more independent items -
+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.
+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
+--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.
 Routing: `{ROUTE_BIN} "<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
@@ -400,12 +412,30 @@ experiments/variants, or producing a research artifact (report, figure, dataset)
 It is NOT "where is X defined" or "who calls Y" - that is code discovery and
 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 `{RESEARCH_BIN} 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
+picks the method, not the tooling: a qualitative, conceptual or reference question
+is a source review (`--method qualitative`: no metric, no experiment), and a
+metric, a locked evaluation and the experiment tree belong only to a question
+whose answer is a measurement (`--method measured`). A plain factual or reference
+question gets no line at all: answer it in the reply from primary sources. Depth
+is the primary source read, not more breadth - the spec, the paper, the code, the
+vendor's own documentation - each finding citing the source it rests on and
+stating its confidence (high, medium or low, and why); a summary of summaries is
+not an answer.
+
 When the task is research and the OpenResearch CLI (`{ORX_BIN}`) is installed,
 drive it through that CLI instead of ad-hoc local scripting. Load the operating
 manual first: the `orx` skill if the host has it, otherwise run
-`{ORX_BIN} skill` from the shell; then
-the named modules (`{ORX_BIN} skill experiment-tree`, `{ORX_BIN} skill lit-review`,
-`{ORX_BIN} skill evidence`, ...). Its cardinal rules are not style preferences - they
+`{ORX_BIN} skill` from the shell; then the module the method needs -
+`{ORX_BIN} skill lit-review` for sources, `{ORX_BIN} skill experiment-tree` and
+`{ORX_BIN} skill evidence` 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
 command and environment are a fixed contract identical on every node; vary the
@@ -420,7 +450,8 @@ afterwards - and `{RESEARCH_BIN} check` refuses a claim that claims a wider scop
 than the rows it rests on.
 
 If the CLI is not installed, say the research tooling is unavailable and do not
-improvise its protocol; fall back to a host subagent and say so. Kill switch:
+improvise its protocol; fall back to a host subagent and say so, briefed with the
+question verbatim, its in- and out-of-scope items and its method. Kill switch:
 `research-off`.
 
 Keep the line auditable in the repository, not in your head:
@@ -437,11 +468,13 @@ into a refusal. A report owes an independent review (`reviewer` is not the
 construct and conclusion validity threats, whatever `phase` says. `state.json`
 `deliverable` names what the line delivers and lists the ask's items, each
 answered in the report, a decision or a claim `trace`, or written `A<n> not
-delivered: <reason>`. A design, plan or analysis is produced as >= 3 variants in
+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 `{RESEARCH_BIN} compare`, `decision.md`
 naming the chosen id, each rejected id with the criterion that ruled it out, and a
-`flip:` condition; a new version of a line is opened `init --supersedes <old>` and
+`flip:` condition (an analysis answers its question once); a new version of a
+line is opened `init --supersedes <old>` and
 carries the old one as a variant. Code or config variants are sibling orx nodes
 under one head node. Literature is found with `{ORX_BIN} discover` and read with
 `{ORX_BIN} paper`; an agent's summary is indexed as `agent-report` and never alone
@@ -602,7 +635,7 @@ prefers shell tools; that preference does NOT cover definitions, callers, or
 blast radius - those go to the graph. The graph answers from a parsed call
 graph, so it beats text search on renames, dynamic dispatch and cross-file
 callers. On Claude a PreToolUse hook denies the Explore subagent here and nudges
-the first identifier-shaped Grep per session toward the graph. The MCP tool's
+the first code-symbol search per session toward the graph. The MCP tool's
 schema is deferred: on the FIRST code-discovery step of the session load it -
 ToolSearch("select:mcp__codegraph__codegraph_explore,mcp__plugin_tezgah_codegraph__codegraph_explore")
 (the plain name on a checkout's own server, the `plugin_tezgah_` one on a plugin
@@ -645,27 +678,40 @@ it - no apology theater, no self-justifying phrasing.
 **Ponytail (minimal code).** Laziest solution that works: YAGNI -> reuse an
 existing helper -> stdlib -> native platform feature -> installed dependency ->
 one line -> minimum code. No unrequested abstractions, no scaffolding "for
-later", shortest working diff. Trace the problem fully before climbing; never
-simplify away validation, error handling, security or anything requested. Bug
-fix = root cause where all callers route through. A deliberate corner cut gets
-a `ponytail:` comment naming the ceiling. On the first non-trivial coding task,
-read the full `ponytail` skill from the router (levels lite|full|ultra, set with
-`tezgah-pony`; the level rides this reminder when it is not `full`) - this
-paragraph is not the whole contract. Off: "stop ponytail".
+later", deletion over addition, fewest files, shortest working diff. Trace the
+problem fully before climbing; never simplify away validation, error handling,
+security, accessibility or anything requested, and build the full version
+without re-arguing when the user insists. Bug fix = root cause where all
+callers route through. A deliberate corner cut gets a `ponytail:` comment
+naming the ceiling. Non-trivial logic leaves ONE runnable check (an assert
+self-check or one small test); a one-liner needs none. A complex ask ships the
+lazy version and names the fuller one in the same reply instead of stalling.
+Reply: code first, then at most three lines - what was skipped, when to add it.
+In force from the first turn; levels lite|full|ultra are set with `tezgah-pony`
+and ride the per-turn reminder when not `full`; read the full `ponytail` skill
+from the router for the level table and examples. Off: "stop ponytail".
 
 **Output shape: ADHD-friendly.** The answer or the next action is on the first
-line, prose after it. Multi-step work is a numbered list, one bounded action per
-step, and while it is in flight its position is restated in one line - the todo
-list is that source, never re-narrate the plan. End with one concrete next step.
-Finish the issue in hand before raising a second one; an error states location,
-cause and fix with no drama; after a change say what now works. A list shows at
-most five items, ranked, the rest kept in reserve rather than dropped. An
+line - a command, path, snippet or the decision itself, never context or the
+question restated - prose after it. Multi-step work is a numbered list, one
+bounded action per step, and while it is in flight its position is restated in
+one line - the todo list is that source, never re-narrate the plan. End with one
+concrete next step. Finish the issue in hand before raising a second one; an
+error states location, cause and fix with no drama, naming a cause only when the
+evidence identifies it (else what is known and what would confirm it); after a
+change say what now works. A list shows at most five items, ranked, the rest
+kept in reserve rather than dropped - presentation only, never the analysis. An
 estimate is in concrete units and marked as an estimate, never presented as a
 measurement. No preamble, no recap, no closer, and a question the reader raises
-mid-work is answered rather than deferred as the second issue. On the FIRST
-non-trivial answer of the session, read the full `i-have-adhd` skill from the
-router - this paragraph is not the whole contract. Off: `tezgah-adhd off`, or
-the repo's `.no-adhd`.
+mid-work is answered rather than deferred as the second issue. Break the shape
+only where it would delete the answer: an explanation runs as long as it needs,
+with headers; an options question gets two to four ranked options,
+recommendation first; 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 or asks "anything else?", any
+by-the-way sidebar and any hedge that carries no real uncertainty. In force from
+the first answer; read the full `i-have-adhd` skill from the router for the
+examples. Off: `tezgah-adhd off`, or the repo's `.no-adhd`.
 
 **Deliver the whole ask; never the shortcut.** The request defines the
 deliverable: every named item is in scope until the user says otherwise, and the
@@ -756,19 +802,30 @@ Off: `consult-off`.
 
 **Research: route it to OpenResearch.** When a task is research - a literature
 or reference review, forming and testing hypotheses, running or comparing
-experiments, producing a research artifact - drive it through the OpenResearch
-CLI (`{ORX_BIN}`) and load its manual first (`{ORX_BIN} skill`), following its
-experiment-tree rules instead of improvising the protocol. Plain code discovery
-stays on the code graph, not OpenResearch. At most one line is open at a time:
+experiments, producing a research artifact - lock it to the question asked:
+restate the user's question verbatim as the scope, name what is in and out of it
+(`init --ask --in --out`), and drop every finding that does not answer an
+in-scope item; never widen it or chase an adjacent topic. The question picks the
+method: a qualitative or reference question is a source review (`--method
+qualitative`, no metric, no experiment); metrics and the experiment tree only
+when the answer is a measurement (`--method measured`). A plain factual or
+reference question gets no line and no orx experiment: answer it in the reply.
+Depth means primary sources read and cited, each finding with its confidence,
+not a thin summary. Drive the work through the OpenResearch CLI (`{ORX_BIN}`)
+and load its manual first (`{ORX_BIN} skill`; `lit-review` for sources,
+`experiment-tree` for a measured line) instead of improvising the protocol.
+Plain code discovery stays on the code graph, not OpenResearch.
+At most one line is open at a time:
 while one is under way - not `concluded`, or carrying a live proposal, an unrun
 experiment, a missing report or review, an unlabelled review finding - no new line
 opens until it is closed or `{RESEARCH_BIN} close <slug> --limit "<reason>"` records
 what is left. `{RESEARCH_BIN} init` refuses on that rule and names each open line;
 `--allow-open "<reason>"` passes it (never beside a line `check` fails) and logs why.
-A plan, design or analysis is >= 3 variants compared under criteria committed
-first (`decisions/`); one version is not a finished line.{OPEN_LINES}
+A design or plan the user will choose between is >= 3 variants compared under
+criteria committed first (`decisions/`); an analysis answers its question once.{OPEN_LINES}
 If the CLI is not installed, say the research tooling is unavailable and fall
-back to a host subagent. Off: `research-off`.
+back to a host subagent briefed with the question verbatim, its in/out scope and
+its method. Off: `research-off`.
 
 **Product analysis: five axes, one evidence class per finding.** A product
 question - "analyse this product", "why is retention falling", "which feature
@@ -826,7 +883,9 @@ Never install, upgrade, restart or kill anything for tezgah, and never open an
 issue for one of its tools mid-session. Name a missing capability in one line,
 use the documented fallback (grep/find, or the second opinion skipped), and carry
 on with the task in hand. Tezgah maintenance is in scope when the user asks for
-it, or when the repo IS the tezgah checkout.
+it, or when the repo IS the tezgah checkout. Before working a topic an
+installed skill covers, run `tezgah-skill <words>` and read only the range it
+returns.
 
 **Workspace: `.tezgah/` only.** Every per-project tezgah artifact - plans,
 research lines, analysis, lessons - lives under `<repo>/.tezgah/`, which the
@@ -835,6 +894,21 @@ project's `.gitignore` excludes and which keeps its own private git repository
 project root and never `git add -f` anything under `.tezgah/`. Off:
 `workspace-off`.
 
+**Parallel by default: fan out independent items.** A request with two or
+more independent items - a numbered or bulleted list, several files or areas, a
+todo list whose entries share no file and no interface - is delegated without
+being asked: one subagent per item, all spawned in ONE message, while the main
+thread decomposes, integrates, verifies and reports. Every writing slice gets
+its own branch and checkout - inside Orca `orca worktree create --name <slug>
+--parent-worktree active --json`, else `git worktree add -b <branch> <absolute
+path>`; its brief names every read, edit and shell `cwd` as an absolute path
+under that checkout, never the main checkout, whose `git status --short` must
+not grow. Read-only slices need no worktree. Pick each agent by task class from
+the specialists line; `{ROUTE_BIN}` names the tier for code work. Serialize
+only a real dependency - one slice's output is another's input, or two slices
+edit one file - and say which. Never wait idle on a spawned slice while
+independent work remains. Off: `orchestrate-off`.
+
 **Kill switches:** each one removes its own rule from this text, not just the
 status mark. `~/.config/tezgah/`: `exec-mode.off`, `orchestrate-off`,
 `consult-off`, `research-off`, `ponytail-auto.off`, `adhd-off`, `spec-off`,
@@ -852,13 +926,13 @@ The ponytail intensity level is not a switch: `tezgah-pony lite|full|ultra`.
 # time (hooks/tezgah_context.classify_prompt), because a session that never asks
 # a structural or research question should not carry their text. Keys match the
 # CORE_RULES labels in hooks/tezgah_context.py.
-CONDITIONAL_KEYS = ("spec", "consult", "research", "product", "graph")
+CONDITIONAL_KEYS = ("spec", "consult", "research", "product", "graph", "fanout")
 
 # The always-on replacement for the conditional paragraphs: one line each so a
 # host without a per-turn hook still knows the rule exists and where the full
 # text lives.
 POINTERS = """
-**On-demand rules (armed when the task class matches; full text in the `tezgah-contract` skill).** Spec-first for an underspecified or quality-only ask. A second opinion before a call that is hard to reverse or that one model would answer with unearned confidence. OpenResearch routing for research. Product analysis is a five-axis evidence task - value, usability (the running app, not the source), feasibility (a cited `path:line`), competition, and keep/fix/cut/bet triage - with one named evidence class per finding. The code graph for "who calls X" and "what breaks if Z changes". The design floor a UI turn is judged against is `.tezgah/design-contract.md`: `tezgah-design derive` writes it from the repository's own tokens, `tezgah-design check` measures a change against it, and the `design-contract` skill owns its shape.
+**On-demand rules (armed when the task class matches; full text in the `tezgah-contract` skill).** Spec-first for an underspecified or quality-only ask. A second opinion before a call that is hard to reverse or that one model would answer with unearned confidence. OpenResearch routing for research. Product analysis is a five-axis evidence task - value, usability (the running app, not the source), feasibility (a cited `path:line`), competition, and keep/fix/cut/bet triage - with one named evidence class per finding. The code graph for "who calls X" and "what breaks if Z changes". Two or more independent items fan out to parallel subagents in one message, one git worktree per writing slice. The design floor a UI turn is judged against is `.tezgah/design-contract.md`: `tezgah-design derive` writes it from the repository's own tokens, `tezgah-design check` measures a change against it, and the `design-contract` skill owns its shape.
 """
 
 # The compact per-turn form, inside the <harness-reminder> envelope the hosts

package/hooks/tezgah_research.py

@@ -136,12 +136,20 @@ SOURCE_CLASSES = ("formal", "grey", "agent-report")
 # those warns on it instead of refusing - its rows were written before the rule
 # existed. Each later set is gated on its own number, so a bump never demotes an
 # older set: 2 the standards rules, 3 the ask contract (keyed on the `ask` field),
-# 4 the protocol sections (`_check_protocol_sections`). A `rules` above `RULES` is
+# 4 the protocol sections (`_check_protocol_sections`), 5 the scope lock
+# (`scope_problems`, `trace_problem`, the method-gated evaluation and the analysis
+# that owes no variants). A `rules` above `RULES` is
 # a line a later tezgah wrote, and every reader and writer here refuses it by name
 # (`newer_rules`) rather than judging it by rules it does not know.
 STANDARDS_RULES = 2
 PROTOCOL_RULES = 4
-RULES = PROTOCOL_RULES
+SCOPE_RULES = 5
+RULES = SCOPE_RULES
+# How a rules-5 line answers its question. `qualitative` is a source or
+# reference review and owes no metric; `measured` runs experiments and locks
+# one. The question picks it, not the tooling: a qualitative ask answered with a
+# metric table is the metric-first drift this field exists against.
+METHODS = ("qualitative", "measured")
 
 # What a line delivers, and how many compared variants that takes. `finding` is a
 # line whose deliverable is its claims; the other four are an artifact a reader
@@ -925,6 +933,7 @@ def _check_state(base, errors, warnings, strict):
         errors.append("state.json direction %r is not one of %s"
                       % (state.get("direction"), ", ".join(DIRECTIONS)))
     _check_evaluation(state, errors, warnings, strict)
+    _check_scope(base, state, errors, warnings, strict)
     _check_hypotheses(state, errors)
     _check_sessions(state, errors)
     _check_success(state, errors, warnings, strict)
@@ -1012,6 +1021,8 @@ def _check_evaluation(state, errors, warnings, strict):
     is written where a session reads it (`skills/research/SKILL.md`,
     `docs/research.md`); what it cannot catch is a tolerance its own author sets
     so wide that every candidate passes it."""
+    if _qualitative(state):
+        return
     phase = state.get("phase")
     locked = phase != "bootstrap"
     evaluation = state.get("evaluation")
@@ -1045,6 +1056,77 @@ def _check_evaluation(state, errors, warnings, strict):
                       "move: fill it, or omit the two-gate pair" % (counter,))
 
 
+# --- scope lock (rules 5) ------------------------------------------------------
+# A line answers the question the user asked, by the method that question takes.
+# `scope.in` lists what the answer covers (S1, S2, ... in order) and `scope.out`
+# what it deliberately leaves alone; every claim's `trace` names an in-scope item,
+# so a finding about something nobody asked is refused instead of padding the
+# report. Owner's report, 2026-10-07: research turned every question into
+# metrics, grew past the ask, and wandered into unrelated topics.
+
+def _qualitative(state):
+    return _rules(state) >= SCOPE_RULES and state.get("method") == "qualitative"
+
+
+def _scope_items(state):
+    scope = state.get("scope")
+    items = scope.get("in") if isinstance(scope, dict) else None
+    return [i for i in items if isinstance(i, str) and i.strip()] \
+        if isinstance(items, list) else []
+
+
+def scope_problems(state):
+    """What a rules-5 line is missing to be locked to its question; [] otherwise."""
+    if _rules(state) < SCOPE_RULES:
+        return []
+    problems = []
+    scope = state.get("scope") if isinstance(state.get("scope"), dict) else {}
+    for side, what in (("in", "what the answer covers"),
+                       ("out", "what it deliberately leaves alone")):
+        items = scope.get(side)
+        if not isinstance(items, list) or not [
+                i for i in items if isinstance(i, str) and i.strip()]:
+            problems.append("state.json scope.%s names nothing: list %s, from the "
+                            "user's own question" % (side, what))
+    if state.get("method") not in METHODS:
+        problems.append("state.json method %r is not one of %s: the question picks "
+                        "it - a source or reference question is qualitative and "
+                        "owes no metric" % (state.get("method"), ", ".join(METHODS)))
+    return problems
+
+
+def trace_problem(cid, claim, state):
+    """The refusal for a rules-5 claim that answers no in-scope item, or None.
+    The write path (`claim_problems`) and the checker (`_check_claims`) both
+    call it, so they cannot disagree about what is on topic."""
+    if _rules(state) < SCOPE_RULES:
+        return None
+    items = _scope_items(state)
+    trace = claim.get("trace")
+    for entry in trace if isinstance(trace, list) else [trace]:
+        if not isinstance(entry, str):
+            continue
+        entry = entry.strip()
+        if any(entry in ("S%d" % n, item.strip()) for n, item in enumerate(items, 1)):
+            return None
+    return ("claim %s traces to no in-scope item: its `trace` names S<n> or the "
+            "text of a state.json scope.in entry - a finding that answers nothing "
+            "the user asked is dropped, not reported" % cid)
+
+
+def _check_scope(base, state, errors, warnings, strict):
+    for problem in scope_problems(state):
+        _soft(errors, warnings, strict or state.get("phase") != "bootstrap", problem)
+    if _qualitative(state):
+        ran = [h for h in _experiment_names(base)
+               if os.path.isfile(os.path.join(base, "experiments", h, "results.jsonl"))]
+        if ran:
+            errors.append("state.json method is qualitative and experiment(s) %s "
+                          "recorded results: a measured question is `method: "
+                          "measured` with its evaluation locked first"
+                          % ", ".join(ran))
+
+
 def _check_hypotheses(state, errors):
     """Every hypothesis states something.
 
@@ -1563,7 +1645,8 @@ def _check_claims(base, errors, warnings, roots=(), strict=False):
         superseded.update(_supersedes(give)[0])
     # the token-savings rule is a `PROTOCOL_RULES` rule, so an older line keeps
     # the rules it was opened under
-    sections = _rules(_state(base)) >= PROTOCOL_RULES
+    line_state = _state(base)
+    sections = _rules(line_state) >= PROTOCOL_RULES
     parsed = []
     for n, raw in enumerate(rows, 1):
         raw = raw.strip()
@@ -1599,6 +1682,9 @@ def _check_claims(base, errors, warnings, roots=(), strict=False):
             errors.append("claim %s status %r is not one of %s"
                           % (cid, claim.get("status"), ", ".join(STATUSES)))
         _check_claim_scope(cid, claim, base, repo, errors, warnings, strict)
+        problem = trace_problem(cid, claim, line_state)
+        if problem:
+            errors.append(problem)
         # A superseded claim is the historical row: the line has corrected it in
         # the row that supersedes it, and that row is the one whose numbers are
         # held to their proof here. Warning on the historical statement too would
@@ -1907,6 +1993,9 @@ def claim_problems(claim, base, repo, held=None):
         known = _claim_ids(base) if held is None else held
         problems.extend("claim %s supersedes %s, and no claim in this line carries "
                         "that id" % (cid, ref) for ref in ids if ref not in known)
+    problem = trace_problem(cid, claim, _state(base))
+    if problem:
+        problems.append(problem)
     # The scope rules the checker decides, so the write path cannot record a claim
     # `check` would refuse. The warn class (a claim over fixture rows that declares
     # nothing) is deliberately not repeated: a writer stricter than the checker
@@ -2848,7 +2937,7 @@ def _check_results_append_only(repo, base, state, errors, warnings, strict):
 # 2006), and serial versions fixate on the first option (Dow et al. 2010); the
 # layer used to hold exactly that, v3 -> v4 -> v5 of one plan never compared.
 
-def deliverable_problems(deliverable):
+def deliverable_problems(deliverable, rules=RULES):
     """(problems, variants needed) for `state.json`'s deliverable declaration."""
     if not isinstance(deliverable, dict):
         return (["state.json deliverable is a %s, not the object naming what the line "
@@ -2862,7 +2951,11 @@ def deliverable_problems(deliverable):
     if ask is not None and (not isinstance(ask, list) or not all(
             isinstance(item, str) and item.strip() for item in ask)):
         problems.append("state.json deliverable ask is not a list of the ask's items")
-    default = {"code": 2}.get(kind, 3) if kind in VARIANT_KINDS else 0
+    # rules 5: an analysis answers its question once; variants are for a design,
+    # plan or code the user will choose between, not a way to triple the answer
+    kinds = VARIANT_KINDS if rules < SCOPE_RULES else tuple(
+        k for k in VARIANT_KINDS if k != "analysis")
+    default = {"code": 2}.get(kind, 3) if kind in kinds else 0
     need = deliverable.get("min_variants", default)
     if not isinstance(need, int) or isinstance(need, bool) or need < 0:
         problems.append("state.json deliverable min_variants %r is not a count"
@@ -3250,7 +3343,7 @@ def _check_decisions(repo, slug, base, state, errors, warnings, strict, git):
                   "line delivers a design, plan, analysis or code that is owed "
                   "compared variants, or only findings")
     else:
-        problems, need = deliverable_problems(deliverable)
+        problems, need = deliverable_problems(deliverable, _rules(state))
         errors.extend(problems)
     decisions = _decision_dirs(base)
     if need > 1 and not decisions:
@@ -3910,7 +4003,7 @@ def _variants_owed(base, state):
     deliverable = state.get("deliverable")
     if not isinstance(deliverable, dict):
         return None
-    _problems, need = deliverable_problems(deliverable)
+    _problems, need = deliverable_problems(deliverable, _rules(state))
     if need < 2:
         return None
     for _name, ddir in _decision_dirs(base):
@@ -4688,7 +4781,8 @@ def verdict_problems(state, rows):
     return problems
 
 
-def init(repo, slug, question="", created="", supersedes=None, ask="", tier=DEFAULT_TIER):
+def init(repo, slug, question="", created="", supersedes=None, ask="", tier=DEFAULT_TIER,
+         method="", scope_in=(), scope_out=()):
     """Scaffold a research line. Returns the paths created (never overwrites).
 
     Refuses a slug `slugs()` cannot list - see `valid_slug` - so no caller can
@@ -4702,6 +4796,8 @@ def init(repo, slug, question="", created="", supersedes=None, ask="", tier=DEFA
         path = os.path.join(base, sub)
         os.makedirs(path, exist_ok=True)
     state = dict(STATE_TEMPLATE)
+    state["method"] = method
+    state["scope"] = {"in": list(scope_in), "out": list(scope_out)}
     state["question"] = question
     state["created"] = created
     # every new line is opened under the newest rule set (`RULES` in the