Recursive Work Router v1

Recursive Work Router v1

Human contract

Remember one command:

/recursive-work <what you want to achieve>

Codex-style explicit invocation may use:

$recursive-work <what you want to achieve>

The router chooses the appropriate recursive method and explains its choice. When
durable output is authorized, it stores the evidence in the selected method's run
structure. The user does not need to decide whether a
request is V3, V4, DDE, scoped-delivery, ultra-review, or V12.

Why this exists

The repository contains several useful recursive methods with different proof limits.
Choosing by the most impressive name creates either unnecessary machinery or an
overstated result. The router chooses by the outcome that must be proven.

It is a method selector, not a new universal implementation and not a source of
authority. It delegates to the existing methods and keeps their boundaries intact.

Routing decision

The router evaluates these questions in order:

1. Does the user need understanding, an artifact, an implementation, or observed effect?
2. Is there already an authoritative or reviewed artifact that should be refreshed?
3. Must the work be resumable across sessions or agents?
4. Does the work require independent adversarial review?
5. Does success include deployment, effect measurement, learning, or a new baseline?
6. Does any step require operator or external-effect authority?

The smallest method that can prove the requested outcome wins.

Method catalogue

Recursive analysis

Select recursive-analysis when the output is an understanding of a repository or
system: architecture, components, call paths, services, evidence conflicts, graph
relationships, unreachable code, silos, or gaps.

Expected output:

• A bounded evidence-backed analysis
• Connected and disconnected relationships
• Contradictions and unknowns
• No build, deployment, or effect claim

This is the operational home for the recovered V3 prose-led reasoning and V4 typed,
replay-oriented analysis blueprint.

Scoped delivery

Select scoped-delivery when the result must be a persistent, resumable package with
scope, supply, nodes, dependencies, decisions, evidence, review, recovery, validation,
and a deterministic lock.

Its planning-time DDE intake is the preferred recursive breakdown front end. DDE
generates a candidate tree. The deterministic pipeline validates the package and
refuses degraded provenance. The candidate generator is never the closure authority.

Expected output:

• Persistent run package
• Existing-supply reconciliation
• Recursive nodes with acceptance criteria and dependencies
• Explicit decisions and gaps
• Deterministic validation and byte-integrity projection
• Honest local proof boundary

The current pipeline does not establish external deployment or effectiveness. Its
declared proof scope remains local scope, structure, projection, and byte integrity.

DDE

Use DDE only through scoped-delivery planning intake unless a narrow debugging task
requires the low-level engine.

The intended composition is cross-family generation, union, adversarial review,
targeted enrichment, and repeat-until-dry. The ensemble harness implements generation
and one gap-review round. An agent or operator folds independently verified gaps and
repeats the affected branches; --max-rounds does not implement that loop.

Provider-routed ensemble path (planning calls require the selected method's authority):

1. Run .claude/skills/scoped-delivery/scripts/dde_intake.py <problem-file> --ensemble
--must-have <keyword-one>,<keyword-two> without a model ID. Supply at least two
distinct, relevant lowercase domain keywords: the existing guard rejects a tree
unless at least two supplied keywords appear in its top-level components. An empty
keyword list rejects every tree.
2. The harness requests claude_code, openai, deepseek, and gemini; model selection
is delegated to gateway policy, including tenant overrides. Omission of model
does not enforce the separate provider_default_model policy.
3. Preserve the candidate union tree, packet, raw review log, and summary. _from
records requested providers; it is not a receipt of actual contributing families.
Component _from_kind explicitly labels those requests as unverified; generated
trees, packets, and summaries mark actual provider/family diversity unverified.
A successful probe or multiple candidate trees must not be counted as verified
cross-family contribution.
4. Independently verify review completion, provider contribution, and unresolved gaps.
Review subprocess failures propagate as failures; successful process exit alone
is still not substantive review approval or proof of actual family contribution.
5. Before admitting any decomposition into a scoped-delivery package, require its
actual provenance and refuse degraded or missing proof. The ordinary intake emits
strategy_used, degraded, requirement digest and tree digest. The ensemble path
emits a different candidate format and does not preserve that provenance envelope.
A provenance adapter with independent health checks is still required; never copy
ordinary-intake claims onto an ensemble result or manufacture missing fields.
6. Keep ensemble output as candidate evidence until that boundary is satisfied; use
the ordinary intake when its provenance format is required and its instrument is
healthy. Fold independently verified gaps and repeat only the affected branches
through the agent/operator outer loop.

Ultra review

Select ultra-review when the user explicitly requests it or when a consequential,
SHA-pinned diff, PR, staged snapshot, or repository section needs multi-perspective
adversarial review.

Do not use it as a generic architecture explorer or as proof that a complete product
is effective. Its subject and verdict scope remain the explicit reviewed artifact.

V12 workflow evolution

Select workflow-evolution V12 when success includes the complete outer loop:

objective -> baseline -> delta -> roads -> operator step -> admitted work -> result ->
residue -> independent review -> readback -> effect -> learning -> new baseline ->
next roads -> operator decision

V12 wraps scoped-delivery leaves. It does not replace their implementation and review
mechanics. The current repository can coordinate bounded leaves and a manual shadow
programme, but it does not yet have a general automated V12 programme DAG or complete
B0-B15 runtime.

Special route: existing CAP/VF work

When the objective names a CAP, VF, SOL, service, or previously reviewed programme:

1. Read the latest status and authority records.
2. Locate the latest demand tree, coverage ledger, execution artifact, and review.
3. Establish freshness against the current source baseline.
4. Preserve valid reviewed work.
5. Resume at the first unproven gate.
6. Do not regenerate a tree merely because its workflow name changed.

Use delivery/methods/CAP-VF-EXERCISE-RECOVERY-STATUS.v1.json as the recovery index
for the historical CAP/VF programme, then refresh its facts before execution.

Standard compositions

Understand only

recursive-analysis

Break down a capability

recursive-analysis for authority/supply context
-> scoped-delivery DDE intake
-> independent gap review
-> deterministic package validation

Deliver a bounded capability slice

reuse or refresh existing breakdown
-> scoped-delivery package
-> implementation
-> independent review
-> exact artifact readback

Complete a compound-learning cycle

V12 outer run
-> scoped-delivery for each admitted leaf
-> independent review
-> deployment readback
-> effect measurement
-> learning candidate
-> new baseline and next roads
-> operator decision

Review an explicit change

ultra-review on one SHA-pinned subject

Do not automatically add V12 to a read-only question. Do not automatically add a deep
code review to a planning request. Do not call all methods merely because they exist.

Required selection disclosure

Before substantial work, emit:

Selected method: <method or composition>
Reason: <what outcome requires it>
Persistent output: <authorized run/report path, or none: response-only>
Claim boundary: <what this work will not prove>

If the selected method changes after new evidence, record the change and reason in the
run package. Do not silently switch methods.

Persistence contract

When durable output is authorized, every non-trivial invocation must leave enough
evidence for another agent or later session to continue without reconstructing the
chat. Follow the user's scope and the selected method's persistence rules. A read-only
analysis with no authorized report creation remains response-only; state that boundary
instead of writing repository files or stopping the analysis to request persistence.

Record:

• Run or report identifier
• Objective and success condition
• Selected method and reason
• Exact source baseline or evidence digest
• Adopted prior artifacts and their freshness
• Generated nodes, decisions, and evidence
• Review subject and verdict scope
• Known gaps and rejected claims
• First unproven gate
• Next safe action

Use the selected method's established directories rather than inventing a second
parallel store. Scoped-delivery runs belong under delivery/scoped-delivery/runs/.
Read-only investigations normally belong under delivery/reviews/ or an existing
programme-specific directory. V12 programme artifacts use their existing tracker and
workflow-evolution locations.

Evidence and claim discipline

Keep these states separate:

Also distinguish UNVERIFIED_RUNTIME from INSTRUMENT_ERROR. Absence of a runtime
probe is not proof of runtime failure, and a broken instrument is not a product verdict.

Model and provider rule

Do not pass a model name through the router. Delegate selection to llm-gateway
policy, which may include tenant overrides as well as provider defaults. Provider
diversity may be requested by provider or family only when the interface supports it
without naming a model; verify actual contribution separately.

infra/scripts/dde_swarm_loop.py uses a provider-family table, not a model table.
The router must preserve that boundary and must not reintroduce model selection at
the call site.

Authority boundary

Routing does not grant authority. The skill may analyze and prepare local artifacts
within the assigned worktree. It must not infer permission to merge, deploy, mutate
Jira, modify a live external system, archive code, purge evidence, or remove another
session's work. Obtain the relevant authorization at the effect boundary.

Examples

/recursive-work explain cortex-mcp and show only connected production paths

Expected route: recursive-analysis.

/recursive-work break CAP-11 into executable leaves and preserve the result

Expected route: existing CAP-11 artifact refresh plus scoped-delivery DDE intake and
independent review, not decomposition from zero.

/recursive-work take CAP-5 from its current state through demonstrated effect and feed the learning back

Expected route: V12 outer run with scoped-delivery leaves, deployment readback, effect
measurement, learning candidate, new baseline, and operator next-road decision.

/recursive-work deeply review PR 123 at its exact head

Expected route: ultra-review on the explicit SHA-pinned subject.