@r1z4x/tezgah 1.5.1 → 1.6.0

package/skills/product-analysis/SKILL.md

@@ -39,7 +39,7 @@ of a product nobody can observe is a hypothesis, and it says so.
 
 | Axis | The question | Standard | The hard rule |
 |---|---|---|---|
-| Value (PM) | is it worth building? | HEART and its Goals -> Signals -> Metrics process (Rodden, Hutchinson, Fu, CHI 2010); Opportunity Solution Tree with the opportunity score (Torres; Olsen) | a metric with no goal above it is dropped; raw counts are refused; an opportunity is a need; three solutions compared against a pre-stated criterion |
+| Value (PM) | is it worth building? | HEART and its Goals -> Signals -> Metrics process (Rodden, Hutchinson, Fu, CHI 2010); Opportunity Solution Tree with the opportunity score (Torres; Olsen) | a metric with no goal above it is dropped; raw counts are refused; an opportunity is a need; solutions are compared under `decisions/` when the user chooses between them |
 | Usability (UX) | can a person actually use it? | Nielsen's 10 heuristics with the 0-4 severity scale; the cognitive walkthrough's four questions; WCAG 2.2 AA, and the W3C WCAG2Mobile note for native apps; Apple HIG or Material 3 for platform feel | a UI claim is read from the running app through `analyze-app` - down to component x state, never inferred from source - and the rendered screen is read, not only the tree; severity is frequency x impact x persistence; each finding says whether it is a provable failure (a WCAG criterion) or a judgement, and how many passes produced it |
 | Feasibility (PE) | does it do what it says? | intended vs implemented | a claim is a cited `path:line` or graph symbol; a doc-vs-code gap is a finding only when **both** sides are cited; when the ask is one feature, the layer matrices decide it |
 | Competition | where does it stand, and where can it lead? | a teardown (architecture, features, process, cost/performance, strategic meaning) with the comparison basis stated **before** comparing; review mining (categorise themes, sentiment per theme, compare to us, name gaps) | every competitor fact carries its artifact and the date it was read; a cost or effort number is a range with its assumptions |
@@ -48,6 +48,29 @@ of a product nobody can observe is a hypothesis, and it says so.
 Calibrate to stage before prescribing: telling a pre-launch prototype to fix its
 dependency graph, or a scaling product to "find product-market fit", is malpractice.
 
+## Metrics
+
+A metric is chosen, not collected. Name one North Star - the value users get, an
+outcome nobody moves directly - and the few input metrics believed to drive it, as
+a tree whose every edge is a hypothesis to test, not a fact (Amplitude, *The North
+Star Playbook*). Each metric in the tree is one record:
+
+| Field | What goes in it |
+|---|---|
+| goal | the HEART goal it traces to; no goal, no metric |
+| signal | the behaviour or attitude that shows the goal moving |
+| definition | numerator / denominator: a count becomes a ratio, a percentage or a per-user average (HEART) |
+| window | the period it is computed over |
+| baseline | what it is compared against: a target, the previous period or a benchmark |
+| direction | which way is good |
+| leading/lagging | whether it predicts the outcome or reports it |
+| logged | yes / no / unknown: is the signal recorded today? |
+| where the data lives | the table, event, export or file it is computed from |
+
+A metric marked `logged: no` is instrumented before anything is promised on it, and
+`unknown` is the gate's first finding. A dashboard ask takes this tree as its input
+and then `design-contract`'s `data-views.md` for the screen.
+
 ## When the ask is one feature: run the coherence pass first
 
 A product question about one feature - an admin screen, a CRUD surface, a form, a
@@ -243,17 +266,20 @@ Run it as a research line, not a monologue: `tezgah-research init <slug>
 --question "..."` under the repository's `.tezgah/research/`, then `check` before
 reporting. Declare the line's `deliverable` in `state.json` as `{"kind":
 "analysis", "path": "<where the analysis lands>", "ask": [<the ask's items>]}`, so
-`check` holds it to three compared solutions and to answering every ask item. On
-top of what `check` already enforces, the analysis contains:
+`check` holds it to answering every ask item. An analysis answers its question
+once - `check` asks no variants of it - and a design or plan the user chooses
+between goes under `decisions/` with at least three variants. On top of what
+`check` already enforces, the analysis contains:
 
 1. Measurement readiness: what is observable today, and what is not.
 2. The objective: one measurable outcome and its Goal -> Signal -> Metric chain.
-3. Opportunities with their evidence class; the candidate solutions recorded as
-   `decisions/<id>/` (the research skill's "Variants"): at least three produced
-   solutions plus the status quo as V0, the criterion set committed in
-   `criteria.json` before any solution is scored, every cell appended with
-   `tezgah-research compare` (a judged cell with two raters), and `decision.md`
-   naming the chosen solution, what ruled out each other one and the `flip:`.
+3. Opportunities with their evidence class. When the user is to choose between
+   solutions, they are recorded as `decisions/<id>/` (the research skill's
+   "Variants"): at least three produced solutions plus the status quo as V0, the
+   criterion set committed in `criteria.json` before any solution is scored, every
+   cell appended with `tezgah-research compare` (a judged cell with two raters), and
+   `decision.md` naming the chosen solution, what ruled out each other one and the
+   `flip:`. Otherwise the analysis names the recommended one and why.
 4. Risks by class - value, usability, viability, feasibility - each with the
    cheapest test that would falsify it.
 5. The usability section: scope (task, section, device, breakpoints), the heuristics
@@ -284,6 +310,17 @@ named in the artifact with the reason it was not - an element inside a section,
 only a section: a state matrix left out silently, an image test never run, an
 axe-core sweep dropped or a scorecard dimension missing all read the same way.
 
+## The product flow notes
+
+Under `product-flow`, the axes' findings land in `.tezgah/analysis/<topic>/flow.md`,
+one `## <step>` heading per step. A metric from section 2 goes under `## metrics`
+with its full record and the need it rests on. A risk from section 4 goes under
+`## assumptions` with its kind (a value risk is desirability). A triage row goes
+under `## decision` with its metric, threshold and `observe after: YYYY-MM-DD`,
+the date its timeframe ends. A metric the decision names that is not logged yet
+goes under `## instrumentation` with the event or query that will log it. The
+`product-flow` skill gives the order of the steps.
+
 ## The scorecard
 
 Score each dimension 1-5 and report the mean with its anchors; the anchors are the
@@ -299,8 +336,8 @@ any dimension at 1, reject.
 | Depth | does every screen reach component x state, and is anything measured rather than eyeballed? |
 | Image evidence | were the rendered screens actually read - the blur and grayscale tests, the breakpoints, dark mode - or only the tree? |
 | Axis coverage | are all five axes addressed or explicitly excluded? |
-| Metric integrity | does the metric trace to a goal, and is it a ratio with a definition? |
-| Solution plurality | were at least three solutions compared against a pre-stated criterion? |
+| Metric integrity | does every metric trace to a goal and carry its full record - a ratio with its definition, window, baseline and `logged` answer? |
+| Solution plurality | when the user chooses between solutions, were at least three compared under `decisions/` against criteria committed first? |
 | Feasibility grounding | is the implementation claim a cited code path, not an inference? |
 | Decision quality | does every feature end keep / fix / cut / bet, with a criterion and an owner? |
 | Scope calibration | does the analysis say what it did not look at, and what would flip it? |
@@ -333,6 +370,8 @@ Read the one that matches the axis; never cite these from memory.
 - `phuryn/pm-skills` (MIT) - `pm-data-analytics` (cohort, A/B), `pm-ai-shipping`
   (security and performance audits, test-coverage map), the rest of discovery.
 - HEART, `https://research.google.com/pubs/archive/36299.pdf` (CHI 2010).
+- The North Star and its inputs, leading and lagging: Amplitude, *The North Star
+  Playbook*, `https://amplitude.com/books/north-star/about-the-north-star-framework.md`.
 - Nielsen's 10 heuristics and the severity scale,
   `https://www.nngroup.com/articles/ten-usability-heuristics/` and
   `https://www.nngroup.com/articles/how-to-rate-the-severity-of-usability-problems/`.

package/skills/product-flow/EVALS.md

@@ -0,0 +1,81 @@
+# Evals
+
+Three inputs a session can be handed where this skill could misfire, and what a
+good answer has to contain. Each case is built so a plausible but shallow answer
+fails at least one check.
+
+Run a case by giving the session only the **Input**, with the skill reachable
+from the router. A case passes when every Must-contain line is met and no
+Must-not line is triggered.
+
+---
+
+## Case 1 - The trap: drawing the dashboard before the flow says so
+
+**Input**
+> Bu veriye uygun bir metric dashboard tasarla. (attached: `sales.csv` - date,
+> region, product, orders, revenue, returns)
+
+**Must contain**
+- [ ] Picks one kebab-case topic and runs `tezgah-research next --topic <t>` before any layout, and does the first missing step it names
+- [ ] Writes each step's note under its `## <step>` heading in `.tezgah/analysis/<t>/flow.md`, each naming the note it rests on
+- [ ] Takes the metrics from `## metrics` notes that rest on a need under `## research` (goal, signal, definition, window, baseline, logged), written before the design step
+- [ ] Gives the decision under `## decision` a metric, a threshold and an `observe after: YYYY-MM-DD` date
+- [ ] Names that decision in `.tezgah/analysis/<t>/spec.md` and in the design-contract component
+
+**Must not**
+- Lay out charts for the CSV's columns before a metric and a decision exist
+- Skip a step whose artifact is missing because the data seems to answer it
+
+**Why this case** - the skill says to "find the first step whose artifact is
+missing" and do "that step, and only that step". A data file pulls toward drawing
+its columns at once.
+
+---
+
+## Case 2 - The trap: a research worker writing the flow's artifacts
+
+**Input**
+> We want to add saved searches to the app. Spin up research on how users
+> re-run searches and take it from there.
+
+**Must contain**
+- [ ] Runs `tezgah-research next --topic <t> --flow feature` (no metric is in view) and starts from the first missing step
+- [ ] Briefs any research worker to report its sources and insights - class, source with its read date, quote, statement, confidence - in its result
+- [ ] Writes those findings under `## research` in `flow.md` from the main session
+
+**Must not**
+- Let a worker or subagent write `flow.md` or `spec.md` itself
+- Start the forward spec before `## decision` exists
+
+**Why this case** - "Who writes" says "Only the main session writes the flow's
+artifacts". A delegated research step pulls toward letting the worker write its
+own findings.
+
+---
+
+## Case 3 - The trap: "just build the chart"
+
+**Input**
+> Skip the process, just build the chart of weekly revenue. No need for metrics
+> or goals.
+
+**Must contain**
+- [ ] Runs `next` for the topic and states which steps are missing before the build, naming the metric and the decision
+- [ ] Says the chart has no goal above it, and asks for the goal or writes the gap down as a step still missing
+- [ ] Offers the shortest route through the missing steps, one note each, rather than refusing
+
+**Must not**
+- Build the chart and report the flow as done
+- Claim the metric or decision steps do not apply to this ask
+
+**Why this case** - every step's artifact "names the earlier artifact it rests
+on": a built chart with no metric and no decision leaves the earlier steps missing
+however good the chart is.
+
+---
+
+## What these do not prove
+
+These are trap cases for a human or judge rater, not a behavioural measurement.
+`skills/research` owns the standard a claim about behaviour has to meet.

package/skills/product-flow/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: product-flow
+description: >
+  Carries a new product capability from evidence to a measured result: it walks
+  the nine steps of the flow in order - research, metrics, assumptions,
+  decision, instrumentation, forward spec, design, build, re-measure - and does
+  the first step whose artifact is missing with the skill that step names, so
+  each hand-off is a written artifact that names the one before it instead of a
+  memory. Use when a session must design a metric dashboard, a new metric or a
+  new feature from data or an ask, and carry it from research to re-measure. Not
+  for auditing an existing feature - use `feature-audit`.
+---
+
+# product-flow
+
+A new product capability - a dashboard over a data file, a metric, a feature
+someone asked for - drifts when its steps live in the session's head: the chart
+gets drawn before anyone says which goal it serves, and nobody comes back to see
+whether the decision held. This skill keeps the sequence written down: the steps
+below, in order, each leaving an artifact on disk that names the artifact it
+rests on.
+
+## When to use it
+
+- A new capability from data: "bu veriye uygun metric dashboard tasarla", a CSV or
+  export with "what should we track".
+- A new capability from an ask: "add a feature that ...", "we need a metric for ...".
+- A topic already in progress, to see what is left of it.
+
+Not for an existing feature's audit (`feature-audit`), and not for a product-wide
+analysis with no new capability in view (`product-analysis`). Both are steps this
+flow can hand off to.
+
+## The steps
+
+Pick one kebab-case topic for the capability, such as `signup-dashboard`. Every
+artifact of this capability lives under `.tezgah/analysis/<topic>/`: the notes of
+steps 1-5 and 9 in `flow.md`, one `## <step>` heading per step, and the forward
+spec in `spec.md`. Each step's artifact names the earlier artifact it rests on.
+
+1. **research** (`research` skill). At least one external source - its URL or
+   title, the date it was read and the passage it says - and the user need or
+   insight that source supports.
+2. **metrics** (`product-analysis`). Each metric rests on a need from step 1 and
+   states its goal, signal, definition, window, baseline, and whether it is
+   logged today.
+3. **assumptions** (`product-analysis`). The assumptions the decision will rest
+   on, each one a sentence that could turn out false.
+4. **decision** (`product-analysis`). A decision that names one of the topic's
+   metrics, the threshold that would change it, and the date after which it is
+   re-measured (observe after).
+5. **instrumentation** (`product-analysis`). Every metric the decision names is
+   logged; a metric that is not logged yet gets the event or query that will log
+   it.
+6. **forward-spec** (`feature-audit`, forward mode). `.tezgah/analysis/<topic>/spec.md`,
+   naming the decision it implements.
+7. **design** (`design-contract`). A component in `.tezgah/design-contract.md`
+   that names the decision it serves.
+8. **build** (`design-contract`). Judged by the design check
+   (`tezgah-design check`) and the Stop UI rule, not by this flow.
+9. **re-measure** (`analyze-app`). Once the decision's observe-after date has
+   passed, measure the decision's metric again and write the result and what it
+   means for the decision.
+
+A feature ask that names no metric skips steps 2 and 5, unless the topic already
+holds a metric.
+
+## The loop
+
+The step source is `~/.config/tezgah/bin/tezgah-research next --topic <t>` (`--flow feature` for a feature ask): a step is done once `flow.md` holds its `## <step>` heading (design and build too) or, for the forward spec, once `spec.md` exists, and the re-measure is due once the decision's `observe after: YYYY-MM-DD` has passed.
+
+1. Read what already exists under `.tezgah/analysis/<topic>/` and find the first
+   step whose artifact is missing, or the re-measure whose date has passed.
+2. Do that step, and only that step, with the skill it names. Read that skill; it
+   says what the step's artifact holds.
+3. Write the artifact, naming the artifact it rests on.
+4. Go back to 1. Stop when every step's artifact exists, or when the only step
+   left is a re-measure whose date has not come yet.
+
+## Who writes
+
+Only the main session writes the flow's artifacts. A research worker, a subagent
+or a specialist reports its sources and insights - the class, the source with the
+date it was read, the quote, the statement and its confidence - in its result, and
+the main session writes them down.
+
+## What this skill does not do
+
+It does not decide what a metric is, how a dashboard looks or what a feature spec
+holds: the skill each step names owns that (`product-analysis`, `research`,
+`feature-audit`, `design-contract`, `analyze-app`).

package/skills/research/SKILL.md

@@ -69,7 +69,8 @@ breaking one silently invalidates the run:
 Load its manual before driving it: `orx skill`, then the module for the step
 (`orx skill lit-review` for sources; `orx skill experiment-tree` and
 `orx skill evidence` for a measured line).
-Local runs need no login; managed compute does - ask the user to run `orx login`.
+Local runs need no login; managed compute does - run locally at a scale that fits,
+and ask for `orx login` only when the question cannot be answered without it.
 If `orx` is absent, say the research tooling is unavailable and do not improvise
 its protocol; the workspace below still applies to whatever you run instead.
 
@@ -578,6 +579,14 @@ palette rather than the default cycle; and size for the venue's column width whe
 the figure is headed into a paper. The library's `index/6-write.md` entries carry
 the full rules when a line reaches that stage.
 
+## A source that answers a product ask
+
+When a line's source answers a product question under `product-flow`, the finding
+also goes under `## research` in `.tezgah/analysis/<topic>/flow.md`: the source's
+URL or literature path, the date it was read and the passage it says, then the
+user need it supports. A research claim it rests on is cited as
+`<slug>:<claim id>`. The `product-flow` skill gives the order of the steps.
+
 ## Provenance, at the end of the session
 
 Research is a sequence of decisions, and the next session does not remember them.

package/skills/tezgah-contract/SKILL.md

@@ -83,41 +83,46 @@ 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)
 
-The user can make one open plan the session's active task, and two optional
+The orchestrating session makes one open plan its active task, and two optional
 frontmatter keys are the whole record: `phase:` (`discovery`, `implementation`
 or `verification` - at most one open plan carries it) activates the plan, and
 `allowed_paths:` is the `- glob` list its writes have to stay inside. Rule 10 of
-the tool gate reads it and refuses four things before they land: a write while
+the tool gate reads it and refuses three things before they land: a write while
 the phase is `discovery` (writes belong to `implementation` or `verification`)
 or one outside the globs; a shell command that writes a file while the phase only
 reads - the shell is a write route like any other, and E7b measured it as the one
 an agent takes once the write tools are refused - matched over redirects, `tee`,
 the in-place editors, `cp`/`mv`, `patch` and `git apply|restore|checkout --`, so
 a `> /dev/null` and a quoted `>` are not writes and the allowlist is not
-consulted (a shell line's targets are not read); a write whose target is the
-record itself, refused whatever the phase and the globs say; and a shell command
-that would move the record through the CLI. None of the four names the command
-that lifts it: the phase and the allowlist are the user's to change, so the way
-out of a refusal is to ask them, or to do the reading this phase asks for and
-say what the write was for. An absent or empty allowlist is no scope asked for rather than "nothing
-allowed", and no active task means no requirement at all - but the CLI will not
-enter `implementation` or `verification` with none: plan-add writes the plan's own
+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,
+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`
+an approving review - which is why the record's own file is refused to a write. An
+absent or empty allowlist is no scope declared rather than "nothing allowed",
+and no active task means no requirement at all - but the CLI will not enter
+`implementation` or `verification` with none: plan-add writes the plan's own
 `allowed_paths:`, `start` without `--allow` keeps them, and only an explicit
-`--any-path` grants every path, so hand the user the command with the plan's scope
-intact. The record is the
-user's own - `~/.config/tezgah/bin/tezgah-task start|phase|allow|stop|status`
-writes it and the agent never runs it, which is why the rule refuses a session's
-own write to the record and a session's own call to the CLI that would change
-it, not just the write the phase or the globs block. The phase also rides every
-user prompt as one line naming the id, the phase and the globs - the only
-preventive surface, so the refusal is never the first the session hears of the
-boundary. Off: `task-off`, which removes all four refusals. `tezgah-task review`
-and `close` are the session's: the verification phase asks for the plan's
-acceptance commands run unpiped and a fresh reviewer (the host's `tezgah-reviewer`
-subagent) reading `git diff <base>..HEAD`; `review NNN <reviewer> approve|changes`
-records the verdict, and `close NNN done` refuses a plan without an approve. A
-change with an executable oracle is reviewed by the population under **Review
-population** below, not by one reviewer.
+`--any-path` grants every path, so keep the plan's scope intact; widen it with
+`allow` only when the plan's work genuinely reaches a file, and record why. The
+phase also rides every user prompt as one line naming the id, the phase and the
+globs - the only preventive surface, so the refusal is never the first the
+session hears of the boundary. Off: `task-off`, which removes all three
+refusals. The verification phase asks for the plan's acceptance commands run
+unpiped and a fresh reviewer (the host's `tezgah-reviewer` subagent) reading
+`git diff <base>..HEAD`; `review NNN <reviewer> approve|changes` records the
+verdict, and `close NNN done` refuses a plan without an approve - unless both
+rounds are spent and `--resolved "<fix and the test that proves it>"` records
+what the session fixed itself; nothing waits on the user. `close` on the
+active task deactivates it in the same write, then removes every linked worktree
+whose branch is merged and which holds nothing else, printing each one it keeps
+with the reason. A change with an executable oracle is reviewed by the
+population under **Review population** below, not by one reviewer.
 
 ## Code discovery: prefer the indexed graph over blind search
 
@@ -523,17 +528,32 @@ 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, move the plan to `.tezgah/plans/done/`, and report the outcome. Bring it back
-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
+merge and close the plan yourself (`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
 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.
+what is left is fixed by the session and closed with `--resolved`, or 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.
 
+**The process is yours: never hand a step back.** The orchestrator runs the
+plan lifecycle itself - `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 spend ceiling, a
+sample size, a retry budget, a member to consult) is picked by you: choose the
+conservative default, state it in one line, proceed. A credential, a login or an
+access grant is the one thing no tool supplies, and even then take every route
+that needs none first - another consult member or provider, local compute
+instead of managed, a public source - and ask once, naming what it unlocks, only
+when no route is left. A requested item you would drop is still asked about
+(see "Deliver the whole ask").
+
 **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
@@ -550,8 +570,8 @@ a fixture. There round one becomes a population:
 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.
+   of what it touches. After round two what is left is fixed by the session and
+   closed with `--resolved`, or 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,
@@ -619,11 +639,12 @@ unchecked assumptions, what would change its mind, requested evidence - not a
 paraphrase, because the paraphrase is where the minority view gets dropped.
 
 Exit 4 means no choice is recorded and exit 5 means every recorded member
-failed: nothing answered, and the output lists `offer:`/`reoffer:` members. Ask
-the user which to use with exactly those options (prefer a model family other
-than your own), record the answer with
-`~/.config/tezgah/bin/consult --use <member>[,<member>]`, then ask the question
-again. Never pick a member for the user. The choice lives in
+failed: nothing answered, and the output lists `offer:`/`reoffer:` members. Do
+not ask the user: record the first listed member from a model family other than
+your own with
+`~/.config/tezgah/bin/consult --use <member>[,<member>]`, ask the question
+again and say which member you chose; after two rounds with nothing answering,
+report the second opinion as skipped. The choice lives in
 `~/.config/tezgah/config.json` under `consult`; an agent CLI member runs in an
 empty temp dir, so the packet is all it sees.
 
@@ -688,8 +709,9 @@ 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
 committed code/config, never CLI args or env knobs; grow the experiment tree
-downward, not sideways. Local research needs no login; managed compute does
-- ask the user to run `orx login`.
+downward, not sideways. Local research needs no login; managed compute does -
+run locally at a scale that fits, and ask for `orx login` only when the
+question cannot be answered without managed compute.
 
 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, briefed with the
@@ -824,7 +846,9 @@ recommendation, and every recommendation names the reference that already does i
 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. Kill switch: `research-off`.
+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
+its first missing or due step is the next one. Kill switch: `research-off`.