@kontourai/flow-agents 3.6.0 → 3.8.0

package/kits/builder/skills/design-probe/SKILL.md

@@ -1,74 +1,54 @@
 ---
 name: "design-probe"
-description: "Generic one-question-at-a-time design probing interview for turning unclear goals, designs, or workflow states into shared understanding before planning or execution."
+description: "Generic one-question-at-a-time design probe for turning unclear goals, designs, and handoffs into shared understanding."
 ---
 
 # Design Probe
 
-Use `design-probe` when a goal, design, workflow route, implementation boundary, acceptance criterion, or recovery path is not clear enough to plan or execute responsibly.
+Use `design-probe` when a goal, design, implementation boundary, acceptance criterion, workflow route, or recovery path is not clear enough to plan or execute responsibly.
 
-This skill is generic. It is not Builder Kit-only. Builder Kit uses the flow step name `design-probe` during pickup and guided build workflows, but the same probing contract applies to any project, feature, architecture, product idea, or implementation handoff that needs alignment.
+## Role And Binding
 
-This skill is modeled after Matt Pocock's `grill-me`: interview the user relentlessly about the relevant plan or design until shared understanding exists, walk the design tree branch by branch, provide a recommended answer for each question, ask one question at a time, and explore the codebase or local docs instead of asking when the answer is discoverable.
+- **Role:** standalone shared alignment primitive.
+- **Binding:** none. This skill is not a Builder step producer.
+- **Produces:** a compact decision record in the caller's existing artifact or conversation; no prescribed Builder artifact or expectation.
+- **Standalone no-run behavior:** always run as an independent probe. Do not start, inspect, advance, or record evidence for any Builder flow.
 
 ## Contract
 
-- Explore first: inspect available local docs, plans, artifacts, contracts, code, tests, issue text, and prior decisions before asking the user when the answer is discoverable.
-- Stay grounded: cite the local sources or code paths that shaped the question when they matter.
-- Walk the design tree branch by branch: resolve dependencies between decisions one-by-one before moving to the next branch instead of mixing independent concerns.
-- Be relentless about ambiguity: keep probing fuzzy goals, overloaded terms, implicit non-goals, missing constraints, and weak success signals until they are resolved or explicitly accepted as gaps.
-- Ask exactly one alignment question at a time.
-- Include a recommended answer with every question and briefly explain why it is recommended.
-- Make the recommendation actionable enough that the user can accept it directly.
-- Record decisions, unresolved questions, accepted gaps, and planning readiness as the interview progresses.
-- Stop when shared understanding exists, or when the remaining uncertainty is explicitly recorded as an accepted gap.
-- Do not silently convert uncertainty into implementation work.
+- Explore available docs, plans, artifacts, contracts, code, tests, issue text, and prior decisions before asking for discoverable information.
+- Resolve one decision branch at a time. Ask exactly one alignment question per turn, include a recommended answer, and wait for the response.
+- Keep probing fuzzy goals, overloaded terms, implicit non-goals, missing constraints, and weak success signals until they are resolved or explicitly accepted as gaps.
+- Do not silently turn uncertainty into implementation work.
+- Do not replace backlog shaping, implementation planning, verification, release review, or any flow-specific producer.
 
 ## Model Routing
 
-When this skill delegates its probing/alignment work, resolve the
-`delegate-design` role from `.datum/config.json`
-(`npx @kontourai/datum resolve delegate-design --json`) and pass the resolved
-model explicitly — probing a goal, design, or recovery path needs design
-latitude, so it routes to the design tier. See
-`context/contracts/execution-contract.md` § Delegation: Model Routing. Fallback:
-inherit the session model when datum/config is absent, noted in the artifact.
+When delegating alignment work, resolve `delegate-design` from `.datum/config.json`. If unavailable, inherit the session model and state the fallback in the decision record.
+Apply the routing and escalation contract in `context/contracts/execution-contract.md`.
 
 ## When To Use
 
-Use this skill for:
+Use this primitive for ambiguous product or feature goals, conflicting requirements, missing acceptance criteria, architecture decisions, unclear recovery paths, and uncertain next actions. It may be called by a specialized workflow skill, but it owns no workflow gate or claim procedure.
 
-- Ambiguous product or feature goals.
-- Conflicting requirements or unclear non-goals.
-- Missing acceptance criteria or unclear evidence expectations.
-- Architecture or workflow decisions that block planning.
-- Direct primitive recovery when upstream context or state is missing.
-- Guided workflow next-step selection when artifacts do not clearly identify whether to ask, plan, execute, verify, or stop.
+## Discovery
 
-Do not use this skill to replace implementation planning, backlog shaping, verification, or release review. Use it only until the design decision surface is aligned enough for the next workflow primitive.
-
-## Discovery Before Asking
-
-Before asking the first question:
-
-1. Read the user's request and identify the decision branch that blocks progress.
-2. Search local context that could answer it, such as `README`, `CONTEXT.md`, `docs/`, `context/contracts/`, relevant skills, active workflow artifacts, schemas, tests, and nearby implementation files.
-3. Prefer existing project vocabulary and documented decisions over inventing new terms.
-4. If local evidence resolves the branch, record the inferred decision and move to the next branch.
-5. Ask only when the branch remains ambiguous, contradictory, risky, or value-laden.
+1. Identify the decision branch that blocks progress.
+2. Search local context for the answer and prefer existing vocabulary and documented decisions.
+3. Record an inferred decision when evidence resolves the branch.
+4. Ask only when the decision remains ambiguous, contradictory, risky, or value-laden.
 
 ## Interview Loop
 
 For each unresolved branch:
 
-1. State the branch being resolved in one short sentence.
-2. Ask exactly one question.
-3. Provide a recommended answer in the same message.
-4. Explain the practical consequence of accepting the recommendation.
-5. Wait for the user's answer before asking another question.
-6. Record the outcome before continuing.
+1. State the branch in one short sentence.
+2. Ask one question.
+3. Give a specific recommended answer and its practical consequence.
+4. Wait for the answer.
+5. Record the decision, unresolved question, or accepted gap before moving on.
 
-Question format:
+Use this format:
 
 ```markdown
 Question: <one alignment question>
@@ -78,105 +58,26 @@ Recommended answer: <specific answer the user can accept>
 Why: <brief reason and consequence>
 ```
 
-If the user answers with a new ambiguity, treat that as the next branch. If the user accepts the recommendation, record it as a decision and continue.
-
-## Records
-
-Maintain a compact running record in the active artifact or conversation when no artifact exists:
-
-- `decisions`: choices that are aligned or locally inferable.
-- `unresolved_questions`: questions still blocking planning or execution.
-- `accepted_gaps`: uncertainties the user explicitly accepts, including the consequence.
-- `planning_readiness`: one of `ready`, `needs_more_probe`, or `accepted_gap_ready`.
-- `next_action`: the recommended next workflow step, such as `shape`, `plan-work`, `execute-plan`, `verify-work`, `needs_user`, or `stop`.
-
-When workflow artifacts exist, update the appropriate session, handoff, Probe record, or planning artifact according to the local artifact contract. Do not invent a project-specific storage format when the repository already defines one.
-
-## Docs-Write: Two-Delta Emission
-
-Per `context/contracts/probe-docs-write-contract.md`, when a `decisions` entry above is a **decision subject** — a durable, reusable answer to a named domain question, not an implementation detail or transient planning choice — emit two deltas into durable docs in the same motion, before moving to the next branch:
-
-1. **Vocabulary delta**: the subject noun must exist as a `CONTEXT.md` glossary term. If absent, coin it first (a tight one- or two-sentence `### <Term>` entry); if present, refine the definition when the crystallized decision changes what it says (e.g. an "open" pointer becoming a stated answer).
-2. **Decision delta**: consult `docs/decisions/index.md` and propose revise-vs-create against the existing topic slugs (this includes any `needs-decision` stub already naming the subject); revise the existing topic file in place, or create `docs/decisions/<slug>.md` per `context/contracts/decision-registry-contract.md`. Run `npm run gen:decisions-index && npm run check:decisions` after writing.
-3. **Transcript provenance**: add a `session-archive` evidence ref pointing at this Probe's own session artifact (the live `.kontourai/flow-agents/<slug>/...` path — it does not need to be archived yet).
-
-Example — coining a new term and creating its topic file:
-
-```markdown
-### Retry Budget
-
-The maximum number of automatic retries a workflow step may attempt before routing back to the user. Configured per Flow Definition step, not globally.
-```
-
-```markdown
----
-status: current
-subject: Retry budget
-decided: 2026-07-03
-evidence:
-  - kind: session-archive
-    ref: .kontourai/flow-agents/<slug>/<slug>--design-probe.md
-  - kind: issue
-    ref: https://github.com/kontourai/flow-agents/issues/<n>
----
-
-# Retry budget
-
-Each Flow Definition step declares its own retry budget; there is no global default. Set during design-probe alignment on <n>.
-```
-
-Example — revising a `needs-decision` stub seeded by the ADR-freeze cutover (issue #314) once its frozen ADR's decision is confirmed still current: flip `status: needs-decision` to `current`, set `decided` to today, keep the existing `adr` evidence ref, and append the `session-archive` ref for this Probe session plus a `pr` ref once one exists. See `context/contracts/probe-docs-write-contract.md` § Worked Example for the full step-by-step.
-
-Do not write a numbered ADR — `docs/adr/` is frozen history (`docs/adr/README.md`); every decision delta targets the topic-keyed registry.
-
-## Stop Conditions
-
-Stop probing when one of these is true:
+## Decision Record
 
-- Shared understanding exists and the next action is clear.
-- The user explicitly accepts a gap and its consequence, and the next action can proceed with that gap recorded.
-- The next action is to stop because the goal is out of scope, not worth pursuing, or blocked by an external dependency.
+Maintain, in an existing caller artifact when one exists:
 
-Before stopping, summarize:
+- decisions
+- unresolved questions
+- accepted gaps and consequences
+- planning readiness: `ready`, `needs_more_probe`, or `accepted_gap_ready`
+- recommended next action
 
-- Decisions made.
-- Remaining unresolved questions, if any.
-- Accepted gaps, if any.
-- Planning readiness.
-- Recommended next action.
+For a durable, reusable domain decision, follow the repository's vocabulary and decision-record contract. Keep transient planning choices and open questions in the caller's working artifact.
 
-## Gate Claims: Builder Kit Design-Probe Step
-
-When `design-probe` runs at the Builder Kit `design-probe` flow step and the probe reaches a stop condition with shared understanding or accepted gaps, record the gate claims before handing off to `plan-work`.
-
-This applies whether the probe is run directly (generic) or as part of a Builder Kit productized flow. The `pickup-probe` specialization owns the same two claims when it runs instead.
-
-**Claim 1 — Pickup readiness** (probe passed, goal fit and scope confirmed):
-
-```bash
-npm run workflow:sidecar -- record-gate-claim .kontourai/flow-agents/<slug> \
-  --expectation pickup-probe-readiness \
-  --status pass \
-  --summary "Design probe passed: goal fit confirmed, scope aligned, planning readiness verified." \
-  --evidence-ref-json '{"kind":"artifact","file":".kontourai/flow-agents/<slug>/<slug>--<artifact>.md","summary":"Design-probe artifact with decisions, accepted gaps, and planning readiness."}'
-```
-
-**Claim 2 — Probe decisions captured**:
-
-```bash
-npm run workflow:sidecar -- record-gate-claim .kontourai/flow-agents/<slug> \
-  --expectation probe-decisions-or-accepted-gaps \
-  --status pass \
-  --summary "Probe decisions recorded: decisions made, unresolved questions explicit, planning readiness confirmed." \
-  --evidence-ref-json '{"kind":"artifact","file":".kontourai/flow-agents/<slug>/<slug>--<artifact>.md","summary":"Design-probe artifact with decisions and accepted gaps."}'
-```
+## Stop
 
-Record both claims when shared understanding exists and the next action is `plan-work` or equivalent. Use `--status fail` when stopping due to an unresolved blocker. Skip these claims entirely when `design-probe` is used outside a Builder Kit flow (no active `builder.build` flow step in `current.json`).
+Stop when shared understanding exists, an explicit accepted gap permits the next action, or the correct next action is to stop. Summarize decisions, unresolved questions, accepted gaps, readiness, and the recommended next action.
 
 ## Boundaries
 
 - Do not ask multiple questions in one turn.
-- Do not ask for information already discoverable from local docs, code, tests, schemas, or workflow artifacts.
-- Do not broaden the probe into unrelated architecture review, backlog shaping, or implementation.
-- Do not treat Builder Kit terminology as required outside Builder Kit workflows.
-- Do not overwrite downstream workflow authority: if another contract owns planning, verification, release, or gate semantics, hand off to that contract once probing is complete.
+- Do not ask for information already discoverable from local context.
+- Do not broaden into unrelated architecture review or implementation.
+- Do not use Builder terminology as a prerequisite for this primitive.
+- Do not create or record Builder claims, expectation evidence, or flow state.

package/kits/builder/skills/evidence-gate/SKILL.md

@@ -1,223 +1,81 @@
 ---
 name: "evidence-gate"
-description: "Evaluate whether completed work is trustworthy enough for human review, merge, or release. Use after implementation, verify-work, provider checks, CI, or remediation to map acceptance criteria to evidence, inspect scope integrity, classify failures, assess check health, and produce a confidence report."
+description: "Assess whether verification evidence and scope integrity support merge review. Produces a confidence report and Builder merge-readiness evidence."
 ---
 
 # Evidence Gate
 
-Build confidence with falsifiable evidence, not process completion.
+## Role
 
-Evidence Gate is not Release Readiness. It asks whether completed work has enough trustworthy evidence, scope integrity, and provider/runtime signal to publish the change, continue fixing, or ask for a human decision. Release Readiness comes later and decides whether a published branch/provider change should merge, release, deploy, hold, or roll back.
+This is a Builder step skill.
 
-## Contract
+Evidence Gate assesses whether the completed work has trustworthy, scoped
+evidence for merge review. It does not fix code, publish a change, approve a
+release, or deploy.
 
-- Review evidence after implementation and verification.
-- Do not fix code.
-- Do not mark unverified work as passing.
-- Treat `NOT_VERIFIED` as a first-class outcome.
-- Separate evidence provenance: human-authored, agent-authored, CI-generated, runtime-observed.
-- Do not approve release readiness.
-- After a clean local evidence verdict, require a publish-change gate before `release-readiness`: verified diff committed, branch pushed, provider change opened or updated by the active `ChangeProvider` or an explicit no-provider-change reason recorded, closing refs recorded, provider checks known, and evidence refs linked.
-- Provider-facing summaries, PR/change descriptions, issue comments, closure comments, and final acceptance comments that claim implementation behavior must include an `Acceptance Evidence` table with columns `AC id`, `Status`, `Command/Test Evidence`, `Source Evidence / Permalinks`, and `Gaps`.
+## Binding
 
-## Inputs
-
-- Work brief or selected GitHub issue.
-- Execution plan.
-- Verification report.
-- Provider change / branch / check run links when available.
-- Changed-file summary.
-- Active TODOs, issue links, and release/rollback notes.
-- Cross-repo dependency/provider coverage matrix when work spans multiple
-  products, package-manager roots, generated artifact locations, install
-  scripts, CI, or shared workflow guidance.
-
-## Artifact Contract
-
-Write or update `.kontourai/flow-agents/<slug>/<slug>--evidence-gate.md` with:
-
-- `intent`: issue/brief, acceptance criteria, non-goals, risk class
-- `evidence_manifest`: command/check name, source, timestamp, result, link/output pointer
-- `test_map`: acceptance criterion to evidence tier and gaps
-- `integrity_report`: scope drift, weakened tests/config, sensitive files
-- `ci_report`: checks, reruns, flakes, failures, skipped checks
-- `risk_assessment`: residual risks and required human review
-- `verdict`: PASS, FAIL, or NOT_VERIFIED
-- `next_step`: publish-change, release-readiness, verify-work, execute-plan, plan-work, CI remediation, or human decision
-
-Also write or update structured sidecars:
-
-- `state.json`: phase `evidence`, current status, and required next action
-- `acceptance.json`: final criterion statuses and goal-fit status
-- `evidence.json`: normalized checks, `standard_refs`, external evidence refs, not-verified gaps, and verdict
-- `handoff.json`: next step and blockers when verdict is not a clean pass
+| Context | Binding | Flow expectation |
+| --- | --- | --- |
+| Active Builder run | `builder.build` at `merge-ready` | `merge-readiness` |
+| Standalone invocation | No Flow binding | No workflow mutation. |
 
-Prefer `npm run workflow:sidecar --` for sidecar updates when available, then validate the artifact directory before reporting a clean pass.
+For an active run, confirm the binding before evaluation:
 
-## Workflow
-
-### 1. Anchor To Intent
-
-Restate:
+```bash
+flow-agents workflow status --session-dir <session-dir> --json
+```
 
-- original problem
-- acceptance criteria
-- non-goals
-- expected risk class
-- authoritative artifacts
+Only a matching run may publish `merge-readiness`. A standalone confidence
+report is local and must not call `workflow evidence`.
 
-If acceptance criteria changed after implementation began, flag scope drift unless the decision is documented.
+## Inputs
 
-### 2. Build Test Map
+- The relevant verification and critique slices in `trust.bundle`.
+- Changed-file scope from `RepositoryAdapter` or the execution record.
+- Change and check records from `ChangeProvider` and `CheckProvider` when available.
+- Known risks, accepted gaps, and repository policy evidence.
+
+## Evaluation
+
+1. Operate report-only. Do not patch source, alter checks, publish a change, or
+   rerun with weaker options to manufacture a passing decision.
+2. Confirm acceptance evidence maps to the intended changed scope. Compare the
+   planned scope, actual diff, generated files, and provider-reported change.
+   Unexplained drift, weakened checks, or unrelated edits reduce confidence and
+   must be named.
+3. Classify evidence by strength: direct runtime or test observation; provider
+   check/review record; reproducible command result; source inspection; or
+   unsupported assertion. Preserve command, revision, timestamp, scope, and
+   artifact provenance where available. Prose-only completion claims are not
+   acceptance proof.
+4. Re-run only when the command is safe, relevant, and reproducible. A stale,
+   unavailable, changed, or non-reproducible check is degraded to
+   `NOT_VERIFIED`; a previous pass must not remain current by assertion.
+5. Produce `PASS`, `FAIL`, or `NOT_VERIFIED` for the confidence decision.
+   `NOT_VERIFIED` is the result for missing required proof, unavailable provider
+   information, or unresolved integrity questions.
+6. On a matching active run, publish the decision through the public CLI:
 
-For each acceptance criterion, map evidence to one of:
+```bash
+flow-agents workflow evidence --session-dir <session-dir> \
+  --expectation merge-readiness \
+  --status <pass|fail|not_verified> \
+  --summary "Evidence confidence, scope integrity, and remaining risks are recorded." \
+  --evidence-ref-json '{"kind":"artifact","file":"<session-dir>/<slug>--evidence-gate.md","summary":"Evidence confidence, criterion coverage, and scope-integrity decision."}'
+```
 
-- existing automated test
-- new or modified automated test
-- browser/runtime check
-- static analysis
-- CI check
-- manual/human verification
-- `NOT_VERIFIED` with rationale
+## Output
 
-Block clean pass if high-risk criteria have only indirect evidence.
-Every acceptance criterion must map to evidence or `NOT_VERIFIED`.
-For implementation-behavior claims, each criterion must map to both command/test proof and structured source evidence refs. Source refs require `kind: "source"`, `file`, `line_start`, `line_end`, and `excerpt`; include immutable GitHub blob permalinks pinned to a commit SHA in `url` when a pushed commit/provider URL exists. Local file/line refs are acceptable only as pre-publish fallback evidence.
+Record the confidence report as the `merge-readiness` slice in `trust.bundle`.
+It contains the scope assessed, acceptance evidence, integrity findings,
+evidence provenance, residual risks, `PASS`/`FAIL`/`NOT_VERIFIED` decision, and
+recommended route.
 
-Use this table shape in evidence-gate summaries and provider/closure comments:
+Include a readable `Acceptance Evidence` table when behavior is claimed:
 
-| AC id | Status | Command/Test Evidence | Source Evidence / Permalinks | Gaps |
+| AC id | Status | Command/Test Evidence | Source Evidence | Gaps |
 | --- | --- | --- | --- | --- |
 
-Rows must preserve the original AC ids. If source evidence is missing for a behavior claim, the row must say `NOT_VERIFIED` or name an accepted gap; do not issue a clean pass from prose-only claims.
-
-### 3. Scope And Integrity Check
-
-Check for process gaming or accidental drift:
-
-- scope expanded beyond issue/brief
-- acceptance criteria changed after implementation
-- tests removed or weakened
-- verification config altered
-- CI config altered
-- required CI bypassed
-- sensitive files touched without review
-
-Sensitive areas include auth, security middleware, data migrations, CI config, deployment scripts, feature flags, test helpers, lint/type config, payment, crypto, and filesystem/network operations.
-
-For multi-repo or cross-product changes, require an explicit coverage matrix
-before a clean pass. The matrix must list every affected product/repo root and
-the status of build/test evidence, dependency/security review, provider/CI
-evidence, and any accepted gaps. A clean evidence verdict requires every
-applicable root to be covered or a human-accepted gap recorded with the reason.
-Do not infer cross-product coverage from a passing subset.
-
-### 4. CI And Flake Assessment
-
-Use `github-cli` / `gh` when available.
-
-Record:
-
-- check names
-- pass/fail/skipped
-- rerun count
-- flake suspicion
-- logs or artifact links
-- failure class
-- standard evidence refs when CI emits SARIF, JUnit, TAP, OpenTelemetry, Veritas, or another native proof format
-
-For Flow Agents source changes, prefer the GitHub Actions `Flow Agents CI / Builder Kit Baseline` provider check when present. Its local equivalent is `bash evals/ci/run-baseline.sh`, which writes `evals/results/ci-baseline/summary.md` and command logs. Treat skipped live GitHub mutation checks, LLM acceptance, or unavailable Veritas/governance evidence as explicit skip or `NOT_VERIFIED` entries based on the work's risk class; do not convert the baseline summary into proof that those live lanes ran.
-
-Treat passed-after-rerun as degraded confidence unless explained.
-
-### 5. Evidence Tiers
-
-Classify evidence:
-
-- Tier 0: claim only, no artifact.
-- Tier 1: local command output.
-- Tier 2: automated test tied to acceptance criterion.
-- Tier 3: CI-confirmed test on a clean environment.
-- Tier 4: runtime/browser/production-like verification with trace or log artifact.
-- Tier 5: post-deploy telemetry confirms expected behavior.
-
-Higher-risk work requires stronger tiers.
-
-When an evidence source already has a standard format, keep that format as the native artifact and reference it from `evidence.json`:
-
-- SARIF: static analysis, security, code review, and policy findings.
-- OpenTelemetry logs/traces: runtime behavior, tool/model calls, workflow telemetry, and post-deploy events.
-- JUnit/TAP: test results.
-- Veritas: optional evidence checks, repo standards, and authority settings. Flow Agents records the Veritas reference and verdict but does not own Veritas policy semantics.
-
-Use `context/contracts/governance-adapter-contract.md` before invoking Veritas or any similar governance provider. If the adapter is unavailable, record `NOT_VERIFIED` unless the user explicitly accepts skipping that governance evidence.
-
-### 6. Verdict
-
-Produce:
-
-- `PASS`: evidence satisfies risk and acceptance criteria.
-- `FAIL`: evidence shows the work is wrong or unsafe.
-- `NOT_VERIFIED`: evidence is missing, indirect, blocked, or inconclusive.
-
-For failures, classify:
-
-- implementation defect
-- bad plan
-- bad acceptance criteria
-- flaky infrastructure
-- missing environment
-- security concern
-- product ambiguity
-- scope drift
-
-Include required next evidence and whether to return to `plan-work`, `execute-plan`, `verify-work`, `remediate-ci`, or human decision.
-
-### 7. Publish Change Gate
-
-If the evidence verdict is otherwise `PASS` but the verified diff is not committed, pushed, and represented by a provider change record or an explicit no-provider-change reason, set `next_step` to `publish-change` instead of `release-readiness`.
-
-Use `git` and the active `ChangeProvider` adapter when available to:
-
-- confirm the working tree contains only the verified scope
-- commit the verified diff with a clear message
-- push the branch
-- open or update the provider change record linked to the issue/brief, closing refs, and evidence artifact, or record why no provider change is required
-- include or update the provider-facing `Acceptance Evidence` table, upgrading local source refs to immutable GitHub blob permalinks when the commit SHA and repository URL are known
-- collect provider check/CI links and statuses, or record why provider checks are unavailable
-- keep GitHub PRs as the first `ChangeProvider` adapter example: for GitHub, open or update a PR and collect PR checks
-
-If commit, push, provider change publication, or provider checks are blocked, keep the release path at `NOT_VERIFIED` or `HOLD` until the blocker is resolved or explicitly accepted by the user.
-
-### 8. Dependency And External-Audit Coverage
-
-When dependency review is in scope, evidence-gate must preserve both local
-inventory evidence and external advisory/audit evidence separately. External
-audit commands and registry/advisory lookups may disclose private dependency
-metadata; if the execution policy rejects the command or the user has not
-explicitly approved that disclosure, record the affected roots as
-`NOT_VERIFIED` for external audit and name the privacy/approval blocker.
-
-For cross-product work, a dependency/security lane can pass only when every
-applicable package-manager root has one of these recorded outcomes: `pass`,
-`fail`, `skip_no_manifest`, or an accepted `not_verified` gap. Existing
-vulnerabilities are still `FAIL` for the dependency lane unless the user
-explicitly accepts them as unrelated residual risk.
-
-## Gate
-
-Evidence passes only when acceptance criteria, scope integrity, CI/runtime evidence, and residual risk are sufficient for the risk class.
-
-For an active Builder Flow run, record merge readiness only after this skill reaches `PASS`:
-
-```bash
-npm run workflow:sidecar -- record-gate-claim .kontourai/flow-agents/<slug> \
-  --expectation merge-readiness \
-  --status pass \
-  --summary "Evidence gate passed: verified scope, acceptance evidence, review findings, and unresolved risks support provider review." \
-  --evidence-ref-json '{"kind":"artifact","file":".kontourai/flow-agents/<slug>/evidence.json","summary":"Structured evidence verdict and acceptance coverage."}'
-```
-
-Record `fail` or `not_verified` when the verdict is not `PASS`. The resulting trust bundle is evaluated by Flow and may route back to verification, execution, planning, or Probe according to the canonical definition.
-
-After `PASS`, hand off to `publish-change` when the work is still local, or to `release-readiness` when the verified commit, pushed branch, provider change record or no-provider-change reason, provider checks, closing refs, structured evidence refs, and `Acceptance Evidence` table are available. After `FAIL` or `NOT_VERIFIED`, stop and name the missing work or evidence.
+For a matching active run, publish that report as `merge-readiness`. This is a
+merge-review confidence decision, not release or deployment authorization.