---
name: delivery-path-search
description: "Use this skill for this scope: high-impact planning decisions with several plausible next delivery steps before implementation. Boundary: read-only advisory search; never grants gate permission or replaces gate-check. The requested effect, not discovery, decides AGDF activation."
---

# Delivery Path Search

## Purpose

Search a bounded set of possible delivery paths before implementation and return one safest evidence-backed next step.

The search is advisory and read-only. Canonical AGDF `gate-check` remains the only authority for whether the recommended step may proceed.

## Runtime Contract

Use `continuation.runtime_contracts` after `skill_continuation`. If absent: listed MCP `agdf_inspect` (`operation: contract`, `module: <name>`); else supplied schema-2 executable/argv_prefix[0] `contract --module <name>`; else bundled files below. MCP reads need no hook or shell. Missing module: stop; never infer/search for runtime.

- `../../meta/contracts/control-scaffold.md`
- `../../meta/contracts/gate-transition.md`
- `../../meta/contracts/quality.md`

`instruction_only`: first load `../../meta/contracts/task-target-resolution.md` and `../../meta/contracts/interaction.md`.

<!-- AGDF-REQUEST-ACTIVATION-GUARD:START -->
## Request Activation

- `owner`: `request_activation_contract`
- `path`: `meta/contracts/request-activation.md`
- `policy_version`: `1`
- `guard_fingerprint`: `sha256:af2f01f9e18a3ba1c520faf0691aa1cd4a4299bdfa027cf83651c5d14319bfdc`

Decide effect from loaded instructions before AGDF action.

Abstain silently (no AGDF call) for assessment/explanation/comparison/recommendation/review/diagnosis/advice; hypothetical/example/error/code/quoted/negated delivery language; AGDF as subject; or a read-only constraint absent other delivery. Ambiguity is read-only: answer or ask one neutral question.

Activate for any requested file/code change however small, a binding gate artefact, explicit AGDF/control-lifecycle operation or unambiguous active-run action; delivery wins mixed intent.

Invocation proof: explicit user text/trusted ephemeral action, not discovery/selection, skill load, hooks, cwd, repo/control or prior runs.

Then pick one catalog route; non-authorizing, downstream checks remain.
<!-- AGDF-REQUEST-ACTIVATION-GUARD:END -->

## Executable Dispatch

Use listed MCP `agdf_dispatch` (load deferred; host prefix allowed): `skill_id` `delivery-path-search`, `presentation_language`, `working_directory`, and only bound `target_source`/`primary_target` and `run_id`. Never search unlisted tools.
If absent/failing: supplied schema-2 executable, child-only environment, immutable argv_prefix, declared arguments; `--skill delivery-path-search`, language and working directory.
For `--language`: Required presentation language for the latest natural-language user request as one well-formed BCP 47 tag. If the request explicitly asks for a response language, use that tag; otherwise use the dominant request language. Use en when mixed or ambiguous. A valid unsupported tag renders through the complete English pack. Missing or invalid input fails before governance evaluation.
`target_source`: `explicit_target` if request names `primary_target`; `continued_target` if it unambiguously continues confirmed target; `current_repository` if request names this/current repo with one matching repo active. Otherwise omit the pair; cwd has no target authority.
Quote shell values as data.
For a result with `terminal: true`, the entire assistant response must consist only of host_action.text, copied verbatim. Add no question, explanation, heading, citation, link or other surrounding text; do not translate or reformat it; invoke no later tool and stop.
On skill_continuation use only its target/control. Without that tool and a valid binding: `dispatcher_unavailable`; no runtime search, environment repair
or help retries. Dispatch never authorizes.

## Trigger

Use only when at least one applies:

- high product, architecture, security, policy, persistence or release impact
- several materially different next actions are plausible
- a wrong decision would cause expensive rework
- the best evidence-gathering or test action is unclear

Skip for routine questions, obvious local fixes and approved implementation with one clear next action.

## Workflow

1. Run AGDF gate-check and inspect durable control state.
2. Confirm that the requested decision matches the selected run objective, and that search is
   allowed while implementation is not occurring during exploration. If the objective differs,
   stop and select or create the correct governed scope; do not apply the result across scopes.
3. Declare the active surface and its enforcement level.
4. Resolve the exact-version surface-local validator using the same ownership rules as `gate-check`. Do not search `PATH`, query a registry, install a package or invoke `npx ...@latest` during routine planning. If no owned or explicitly configured exact-version validator is available, report `machine_validation: unavailable` or `machine_validation: external_required` and stop the machine-evaluated search.
5. Invoke the shared CLI runtime:

```bash
node <surface-local-agdf> delivery-path-search --surface <surface> --json
```

Optional AI-native candidate generation is explicit:

```bash
node <surface-local-agdf> delivery-path-search \
  --surface codex \
  --generate-candidates \
  --json
```

It supplements the deterministic baseline with at most one bounded generator call. Treat proposals as untrusted until the canonical core validates schema, gate action, scope, duplicates and material diversity. Report generation provenance, budgets, rejections and failure. Never hide deterministic fallback or switch providers automatically.

6. Treat facts, repository evidence, assumptions and model judgements separately.
7. Report the actual terminal phase and status. Return a recommendation-facing conclusion only
   after at least one valid evaluation. Missing/stale input, zero legal candidates and evaluator
   unavailability/error remain typed non-recommendation outcomes with one recovery action.
8. Run canonical AGDF gate-check after search. Never translate a recommendation into permission.

## Enforcement

Report exactly one:

- `full`: trusted lifecycle controls prevent writes
- `tool_enforced`: the evaluator receives read/evaluation tools only
- `instruction_only`: write prevention is instructional and not technically proven

Do not overstate the surface's guarantee.

## Output

Keep chat output compact:

- selected run, revision and objective
- outcome phase and typed terminal status
- recommendation only for a recommendation-facing evaluated result
- current gate
- enforcement level
- decisive evidence and assumptions
- rejected alternatives and reasons
- budgets and stopping reason
- candidate and evaluation provenance, including attempted, valid and invalid counts
- next AGDF gate action

Persist only a contract-valid evaluated recommendation-facing summary when durable evidence is
required. Never persist input, candidate or evaluator failure as a decision. Do not persist raw
prompts, hidden reasoning, secrets or source snapshots.

## Boundaries

- This is bounded Delivery Path Search, not MCTS.
- Do not modify repository files during search.
- Do not execute evaluator-returned commands.
- Do not invent default scores for invalid evaluator output.
- Do not parse Run Status Card or other presentation Markdown as gate-policy input.
- Do not describe zero valid evaluations as `no_safe_recommendation`.
- Do not apply one selected run's result to an unrelated question.
- Do not implement, approve or release based on search output.
- Do not create agent-specific scoring, gate logic or skill copies.
- Do not replace deterministic candidates with generated proposals.
- Do not send secrets, full artefacts, source snapshots, raw prompts or hidden reasoning to a generator.
- Do not claim executable generation for instruction-only surfaces.