@open-agent-toolkit/cli 0.2.3 → 0.2.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/assets/agents/oat-reviewer.md +59 -3
- package/assets/docs/cli-utilities/project-log.md +16 -0
- package/assets/docs/workflows/projects/reviews.md +88 -1
- package/assets/public-package-versions.json +4 -4
- package/assets/skills/oat-dispatch-subagents/SKILL.md +90 -15
- package/assets/skills/oat-dispatch-subagents/references/provider-claude.md +21 -0
- package/assets/skills/oat-dispatch-subagents/references/provider-codex.md +22 -0
- package/assets/skills/oat-dispatch-subagents/references/provider-cursor.md +66 -15
- package/assets/skills/oat-dispatch-subagents/references/record-schema.md +63 -2
- package/assets/skills/oat-project-autonomous/references/gate-inventory.md +3 -1
- package/assets/skills/oat-project-document/references/docs/autonomy-contract.md +3 -1
- package/assets/skills/oat-project-implement/SKILL.md +14 -5
- package/assets/skills/oat-project-implement/references/docs/autonomy-contract.md +3 -1
- package/assets/skills/oat-project-implement/references/phase-execution.md +35 -2
- package/assets/skills/oat-project-pr-final/references/docs/autonomy-contract.md +3 -1
- package/assets/skills/oat-project-quick-start/references/docs/autonomy-contract.md +3 -1
- package/assets/skills/oat-project-review-provide/SKILL.md +38 -2
- package/package.json +2 -2
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: oat-reviewer
|
|
3
|
-
version: 1.1.
|
|
3
|
+
version: 1.1.8
|
|
4
4
|
description: Unified reviewer for OAT projects - mode-aware verification of requirements/design alignment and code quality. Writes a review artifact to disk by default, or returns structured findings in-memory when dispatched in structured-output mode.
|
|
5
|
-
tools: Read, Bash, Grep, Glob, Write
|
|
5
|
+
tools: Read, Bash, Grep, Glob, Write, Task
|
|
6
6
|
color: yellow
|
|
7
7
|
---
|
|
8
8
|
|
|
@@ -73,6 +73,47 @@ For Codex, deterministic review dispatch under a capped managed policy uses the
|
|
|
73
73
|
|
|
74
74
|
For Claude Code, review dispatch is model-axis based and the effort axis is `not-applicable`.
|
|
75
75
|
|
|
76
|
+
## Bounded Reviewer Reconnaissance
|
|
77
|
+
|
|
78
|
+
The primary reviewer must establish the authoritative scope before considering delegation. Establish its authoritative commit range and read the mode-required discovery, spec, design, plan, and implementation artifacts that are available before decomposition or delegation. Understand the requirements, changed surfaces, and failure consequences in that authoritative scope before deciding whether lanes are independent. Delegation is optional and useful only when the resolved scope has multiple independent evidence lanes. Eligible broad reviews include final code reviews, broad phase/range reviews, docs sweeps, and provider-view audits. Narrow task or artifact reviews stay inline when coordination would cost as much as direct inspection.
|
|
79
|
+
|
|
80
|
+
When delegation is eligible:
|
|
81
|
+
|
|
82
|
+
1. Use one bounded, read-only, non-recursive reconnaissance round with disjoint lane scopes. This is a one-level fan-out limit: lane workers must not spawn additional workers.
|
|
83
|
+
2. Before launching any lane, read `.agents/skills/oat-dispatch-subagents/SKILL.md`, resolve the active provider, and read exactly one matching active-provider reference under `.agents/skills/oat-dispatch-subagents/references/`. Reviewer-local reconnaissance must not read or load `.agents/skills/oat-project-dispatch-subagents/SKILL.md`; that adapter is reserved for project lifecycle phase/task policy.
|
|
84
|
+
3. Map every lane worker to the shared `recon` role class (`role.class: recon`); role authority stays read-only and advisory. Assign the independent `task_class`, `classification_source: caller`, and non-empty `classification_reason` fields after understanding the artifacts and diff. These task-class fields are required for reviewer-local reconnaissance even though the generic dispatch contract keeps them optional for other callers.
|
|
85
|
+
4. Classify each lane as `mechanical-recon`, `intelligent-recon`, `default-implementation`, `hard-reasoning`, or `consequential`. Use the stronger floor when uncertain. Classification proceeds from deterministic verification to silent-miss risk, then dispersed context, ambiguity, and consequence; file count alone never justifies escalation.
|
|
86
|
+
- `mechanical-recon`: deterministic inventories, parity checks, and test/lint/format/build execution whose misses are visible and cheaply checked.
|
|
87
|
+
- `intelligent-recon`: interpretation, semantic completeness, policy-aware auditing, or unfamiliar-code review where a miss could be silent.
|
|
88
|
+
- `default-implementation`: rare, independently bounded dossier work that must retain and reconcile dispersed context; prefer keeping it with the root.
|
|
89
|
+
- `hard-reasoning`: ambiguity, novelty, architecture analysis, or competing interpretations dominate.
|
|
90
|
+
- `consequential`: security, release safety, irreversible impact, or expensive failure dominates.
|
|
91
|
+
|
|
92
|
+
Mechanical workers may execute checks and report exact output, but interpretation and policy judgment require stronger classes or stay with the root reviewer.
|
|
93
|
+
|
|
94
|
+
5. The generic dispatch contract owns capability, catalog, model, effort, route, authorization, launch evidence, class-floor selection, and floor-satisfaction evidence. It applies active user and repository instructions, the active-provider reference, the live nested catalog, and the supplied policy/ceiling. Select an explicit target meeting the declared floor; never silently inherit the primary reviewer's model and never hard-code provider model names. Prefer a cheaper/faster worker only when the host reliably exposes that control and the target still satisfies the floor.
|
|
95
|
+
6. Give each lane an exact scope and a compact return contract: coverage, checks performed, exact `file:line` evidence, gaps, and explicit uncertainty. Reports are advisory candidate observations, not accepted findings.
|
|
96
|
+
7. Workers must not mutate files, emit final findings, assign severity, make validation decisions, write review artifacts or `StructuredFindings`, or otherwise write either output sink.
|
|
97
|
+
|
|
98
|
+
Lanes may share one homogeneous dispatch wave only when every existing dispatch axis, `task_class`, and `model_class_floor` match. Mixed task classes require separate records and waves. The one-level fan-out limit applies across all waves.
|
|
99
|
+
|
|
100
|
+
When delegated reconnaissance is attempted, artifact mode must include a
|
|
101
|
+
compact `## Review Orchestration` section. Record the waves, task classes,
|
|
102
|
+
classification rationale, selected targets, acceptance and outcomes, floor
|
|
103
|
+
satisfaction, fallback, and primary reconciliation. Condense the dispatch
|
|
104
|
+
evidence instead of copying every worker record. In structured-output mode,
|
|
105
|
+
summarize orchestration in the existing `summary`; do not add a field to the
|
|
106
|
+
`StructuredFindings` schema.
|
|
107
|
+
|
|
108
|
+
The primary reviewer owns source validation and verification, reconciliation, synthesis, severity, validation decisions, artifact writing, output ownership, and the final findings or `StructuredFindings`. Reopen authoritative sources and directly re-verify every load-bearing positive and negative claim; repeat relevant searches for absence claims before promotion to a finding. Reconcile overlap, disagreement, and cross-lane gaps across task classes before deduplicating and assigning severity.
|
|
109
|
+
|
|
110
|
+
Capability-check reviewer-local delegation once. A reviewer-local request must use `fallback.mode: caller-inline` and `allow_below_task_class_floor: false`. If the requested floor cannot be explicitly satisfied, record it as unsatisfied, do not launch a below-floor worker, and cover the affected lane inline without weakening review coverage, the checklist, or the output contract. The same inline fallback applies when nested dispatch is unsupported, unauthorized, failed, empty, or malformed. The inline and delegated paths preserve the existing artifact-mode, gate-parsing, and structured-output schemas unchanged.
|
|
111
|
+
|
|
112
|
+
The primary reviewer and lane workers must not write or modify
|
|
113
|
+
`project-log.md` and must not invoke `oat project log append`. The root project
|
|
114
|
+
workflow validates review orchestration evidence and owns any structural log
|
|
115
|
+
entry.
|
|
116
|
+
|
|
76
117
|
## Mode Contract
|
|
77
118
|
|
|
78
119
|
Use workflow mode to determine required evidence:
|
|
@@ -338,6 +379,17 @@ oat_invocation_source: { exec-target-config|unknown }
|
|
|
338
379
|
|
|
339
380
|
Findings: {N} critical, {N} important, {N} medium, {N} minor
|
|
340
381
|
|
|
382
|
+
## Review Orchestration
|
|
383
|
+
|
|
384
|
+
{Include this section only when delegated reconnaissance was attempted.}
|
|
385
|
+
|
|
386
|
+
| Wave | Task class | Classification rationale | Selected target | Acceptance / outcome | Floor satisfaction | Fallback |
|
|
387
|
+
| ---- | ---------- | ------------------------ | ---------------- | -------------------- | ------------------ | -------- |
|
|
388
|
+
| {id} | {class} | {reason} | {target or none} | {status / outcome} | {status} | {route} |
|
|
389
|
+
|
|
390
|
+
**Primary reconciliation:** {independent verification, accepted/rejected
|
|
391
|
+
worker claims, and root-inline coverage}
|
|
392
|
+
|
|
341
393
|
## Findings
|
|
342
394
|
|
|
343
395
|
### Critical
|
|
@@ -414,6 +466,9 @@ For gate-originated artifacts, all six gate-only fields are required when the pr
|
|
|
414
466
|
**Artifact mode only.** In structured-output mode (`oat_output_mode: structured`), return the `StructuredFindings` object instead — see **Structured-Output Mode** below.
|
|
415
467
|
|
|
416
468
|
Return a brief confirmation. DO NOT include full review contents.
|
|
469
|
+
Return exactly one reconnaissance status line using only `attempted` or
|
|
470
|
+
`not-attempted`; this signal reports whether delegated reconnaissance was
|
|
471
|
+
attempted, including an attempted launch that fell back or failed.
|
|
417
472
|
|
|
418
473
|
Format:
|
|
419
474
|
```
|
|
@@ -423,6 +478,7 @@ Format:
|
|
|
423
478
|
**Scope:** {scope}
|
|
424
479
|
**Findings:** {N} critical, {N} important, {N} medium, {N} minor
|
|
425
480
|
**Review artifact:** {path}
|
|
481
|
+
**Reconnaissance:** {attempted | not-attempted}
|
|
426
482
|
|
|
427
483
|
Return to your main session and run the `oat-project-review-receive` skill.
|
|
428
484
|
|
|
@@ -439,7 +495,7 @@ When the dispatch payload sets `oat_output_mode: structured`, the output sink ch
|
|
|
439
495
|
|
|
440
496
|
```typescript
|
|
441
497
|
interface StructuredFindings {
|
|
442
|
-
summary: string; // 2-3 sentence review summary
|
|
498
|
+
summary: string; // 2-3 sentence review summary; include compact orchestration when reconnaissance was attempted
|
|
443
499
|
findings: Array<{
|
|
444
500
|
id: string; // C1, I1, M1, m1 — stable per dispatch (C/I/M/m prefix matches the severity model)
|
|
445
501
|
severity: 'critical' | 'important' | 'medium' | 'minor';
|
|
@@ -93,6 +93,22 @@ entries without asking agents to edit `project-log.md`:
|
|
|
93
93
|
- `oat-project-implement` records accepted subagent dispatches, STOP or park
|
|
94
94
|
events, phase outcomes, and parallel-group merge results. These entries point
|
|
95
95
|
to the corresponding `implementation.md` record instead of copying it.
|
|
96
|
+
- When `oat-project-implement` or `oat-project-review-provide` receives an
|
|
97
|
+
artifact-mode review, the root workflow first consumes exactly one
|
|
98
|
+
`**Reconnaissance:** attempted` or
|
|
99
|
+
`**Reconnaissance:** not-attempted` signal from the reviewer's brief
|
|
100
|
+
confirmation. A missing, duplicate, or invalid signal fails closed before
|
|
101
|
+
artifact validation or bookkeeping.
|
|
102
|
+
- `attempted` requires a complete `Review Orchestration` section recording
|
|
103
|
+
waves, task classes, classification rationale, selected targets,
|
|
104
|
+
acceptance and outcomes, floor satisfaction, fallback, and primary
|
|
105
|
+
reconciliation. The root then invokes `oat project log append` exactly once
|
|
106
|
+
for one structural entry referencing the review artifact instead of copying
|
|
107
|
+
worker records.
|
|
108
|
+
- `not-attempted` forbids a `Review Orchestration` section and does not invoke
|
|
109
|
+
`oat project log append` for review orchestration.
|
|
110
|
+
Reviewers and reconnaissance workers never write `project-log.md`
|
|
111
|
+
themselves.
|
|
96
112
|
- `oat gate review` records exactly one entry for every terminal outcome,
|
|
97
113
|
including successful and blocking verdicts, child failure, timeout,
|
|
98
114
|
targeting-correlation failure, and artifact-validation failure. A log append
|
|
@@ -216,7 +216,7 @@ Final review `passed` gate requires:
|
|
|
216
216
|
|
|
217
217
|
## Subagent Compatibility
|
|
218
218
|
|
|
219
|
-
`oat-project-review-provide` uses provider-aware subagent dispatch when available:
|
|
219
|
+
`oat-project-review-provide` uses provider-aware subagent dispatch when available. This outer dispatch starts the primary `oat-reviewer`; it is separate from any optional reconnaissance workers that the reviewer may launch after resolving its authoritative review scope:
|
|
220
220
|
|
|
221
221
|
- Claude Code: dispatch `oat-reviewer` with `subagent_type` (resolved from `.claude/agents/oat-reviewer.md`).
|
|
222
222
|
- Cursor: dispatch `oat-reviewer` via explicit `/oat-reviewer` invocation or natural mention (resolved from `.cursor/agents/oat-reviewer.md`; `.claude/agents/oat-reviewer.md` is also supported for compatibility).
|
|
@@ -246,6 +246,93 @@ Final review `passed` gate requires:
|
|
|
246
246
|
fallback). This generic fallback does not override managed exact-target
|
|
247
247
|
rules: a managed reviewer that cannot be launched exactly blocks the review.
|
|
248
248
|
|
|
249
|
+
### Reviewer-local reconnaissance
|
|
250
|
+
|
|
251
|
+
After the outer dispatch, the primary reviewer may use reviewer-local workers
|
|
252
|
+
when a broad review has multiple independent evidence lanes. Examples include
|
|
253
|
+
final code reviews, broad phase or phase-range reviews, documentation sweeps,
|
|
254
|
+
and provider-view audits. Running disjoint searches concurrently can reduce
|
|
255
|
+
wall-clock review time, and matching each lane to the least expensive model
|
|
256
|
+
class that can safely do the work can reduce cost. The primary reviewer first
|
|
257
|
+
reads the authoritative diff and the workflow-required discovery, spec,
|
|
258
|
+
design, plan, and implementation artifacts. It decides lane boundaries and
|
|
259
|
+
task classes only after understanding the changed surfaces, requirements, and
|
|
260
|
+
failure consequences. Narrow task and artifact reviews remain inline when
|
|
261
|
+
coordination would cost as much as direct inspection.
|
|
262
|
+
|
|
263
|
+
Worker authority and model capability are independent. Every reviewer-local
|
|
264
|
+
worker keeps the read-only, advisory `recon` role class. The lane's separate
|
|
265
|
+
task class sets its minimum model-capability floor:
|
|
266
|
+
|
|
267
|
+
- **Mechanical recon** covers deterministic inventories, exact parity checks,
|
|
268
|
+
and test, lint, format, or build execution whose results are cheaply
|
|
269
|
+
verifiable.
|
|
270
|
+
- **Intelligent recon** covers semantic interpretation, unfamiliar-code
|
|
271
|
+
auditing, and other evidence where a miss could be silent.
|
|
272
|
+
- **Stronger bounded analysis** is reserved for independently scoped work where
|
|
273
|
+
dispersed context, ambiguity, security, release safety, irreversible impact,
|
|
274
|
+
or expensive failure warrants a higher floor.
|
|
275
|
+
|
|
276
|
+
File count alone does not justify escalation. Interpretation and policy
|
|
277
|
+
judgment either use an adequate stronger class or remain with the primary
|
|
278
|
+
reviewer. Active user and repository instructions, the active-provider
|
|
279
|
+
guidance, and the live nested catalog resolve current model examples; the
|
|
280
|
+
canonical reviewer does not promise named models.
|
|
281
|
+
|
|
282
|
+
Reviewer-local fan-out is limited to one bounded, read-only, non-recursive
|
|
283
|
+
round. Each worker receives a disjoint scope, cannot modify files or spawn more
|
|
284
|
+
workers, and returns a compact advisory report containing:
|
|
285
|
+
|
|
286
|
+
- coverage and checks performed;
|
|
287
|
+
- exact `file:line` evidence;
|
|
288
|
+
- gaps in the assigned scope; and
|
|
289
|
+
- explicit uncertainty, including uncertainty about absence claims.
|
|
290
|
+
|
|
291
|
+
Before launching these lanes, the reviewer loads the generic
|
|
292
|
+
`oat-dispatch-subagents` contract and exactly one active-provider reference.
|
|
293
|
+
That shared contract owns nested capability checks, worker catalog resolution,
|
|
294
|
+
model and effort selection, routing, authorization, launch evidence, and
|
|
295
|
+
provider-specific mechanics. It records each lane's task class, model-class
|
|
296
|
+
floor, classification rationale, and floor satisfaction without assuming that
|
|
297
|
+
workers inherit the primary reviewer's target. Lanes may share one wave only
|
|
298
|
+
when their task classes, model floors, and all other dispatch axes match;
|
|
299
|
+
mixed-class reviews use separate waves and records.
|
|
300
|
+
|
|
301
|
+
This generic reviewer-local use is distinct from
|
|
302
|
+
`oat-project-dispatch-subagents`, which is reserved for OAT lifecycle phase and
|
|
303
|
+
task dispatch policy. Reviewer-local lanes do not load or depend on that
|
|
304
|
+
lifecycle adapter.
|
|
305
|
+
|
|
306
|
+
Worker reports are candidate observations, not findings. The primary reviewer
|
|
307
|
+
reopens authoritative sources, verifies load-bearing positive and negative
|
|
308
|
+
claims, reconciles overlap and disagreement, fills cross-lane gaps, performs
|
|
309
|
+
synthesis, assigns severity, decides validation, and alone writes the review
|
|
310
|
+
artifact or final `StructuredFindings`.
|
|
311
|
+
|
|
312
|
+
When the reviewer attempts delegated reconnaissance, the review artifact
|
|
313
|
+
includes a compact `Review Orchestration` section. It records each wave's task
|
|
314
|
+
class and classification rationale, selected target, acceptance and outcome,
|
|
315
|
+
floor satisfaction, fallback, and the primary reviewer's reconciliation. The
|
|
316
|
+
section is the detailed evidence source; it does not copy every internal worker
|
|
317
|
+
record. Structured-output reviews keep the existing schema and summarize the
|
|
318
|
+
same orchestration evidence in `summary`.
|
|
319
|
+
|
|
320
|
+
The reviewer and its workers never write `project-log.md`. After validating the
|
|
321
|
+
artifact, the root project implementation or review workflow uses
|
|
322
|
+
`oat project log append` to add one concise structural entry that references
|
|
323
|
+
the artifact. Logging remains capability-gated by the CLI helper, so disabled
|
|
324
|
+
project logging requires no reviewer-side branch or write authority.
|
|
325
|
+
|
|
326
|
+
If nested workers are unsupported, unauthorized, fail, or return empty or
|
|
327
|
+
malformed reports, the primary reviewer covers those lanes inline. It also
|
|
328
|
+
stays inline when the host cannot explicitly satisfy a lane's model-class
|
|
329
|
+
floor. Fallback never selects below the declared floor. It preserves the same
|
|
330
|
+
checklist, verification depth, severity policy, and final output contract; it
|
|
331
|
+
does not promise provider behavior or silently inherit the primary reviewer's
|
|
332
|
+
model. Workers remain advisory and non-recursive regardless of task class, and
|
|
333
|
+
the primary reviewer keeps final verification, reconciliation, severity,
|
|
334
|
+
validation decisions, and output ownership.
|
|
335
|
+
|
|
249
336
|
## Reference artifacts
|
|
250
337
|
|
|
251
338
|
- `.oat/projects/<scope>/<project>/plan.md` (`## Reviews`)
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: oat-dispatch-subagents
|
|
3
|
-
version: 1.1.
|
|
3
|
+
version: 1.1.5
|
|
4
4
|
description: Use when an OAT skill or workflow needs provider-neutral selection, launch, recovery, or evidence for bounded subagent work without project lifecycle policy.
|
|
5
5
|
disable-model-invocation: true
|
|
6
6
|
user-invocable: false
|
|
@@ -76,6 +76,19 @@ Require the caller to provide:
|
|
|
76
76
|
- route-selection source for any non-native route;
|
|
77
77
|
- optional resolved dispatch policy or named ceiling.
|
|
78
78
|
|
|
79
|
+
The caller may also provide `task_class`, `classification_source`, and
|
|
80
|
+
`classification_reason`. This task-class metadata is optional for existing
|
|
81
|
+
generic callers. When supplied, all three fields are required:
|
|
82
|
+
|
|
83
|
+
- `task_class`: `mechanical-recon`, `intelligent-recon`,
|
|
84
|
+
`default-implementation`, `hard-reasoning`, or `consequential`;
|
|
85
|
+
- `classification_source`: the literal `caller`; and
|
|
86
|
+
- `classification_reason`: a non-empty artifact-informed rationale.
|
|
87
|
+
|
|
88
|
+
The caller owns classification. `oat-reviewer` requires these fields for every
|
|
89
|
+
reviewer-local reconnaissance lane; other callers that omit them retain
|
|
90
|
+
role-based selection behavior and records without class-floor fields.
|
|
91
|
+
|
|
79
92
|
Reject an over-broad request before selection. Every nontrivial request must
|
|
80
93
|
state the exact objective, scope, expected output, verification evidence, and
|
|
81
94
|
conditions that require escalation. Model routing never repairs poor
|
|
@@ -169,19 +182,55 @@ or a second launch.
|
|
|
169
182
|
|
|
170
183
|
Specific role names are extensible, but map every dispatch to one class:
|
|
171
184
|
|
|
172
|
-
| Class | Default contract
|
|
173
|
-
| -------------- |
|
|
174
|
-
| `recon` | Read-only, bounded evidence collection.
|
|
175
|
-
| `dossier-lead` | Reconcile dispersed evidence within one declared scope. May coordinate bounded recon only when nesting is supported and approved.
|
|
176
|
-
| `generator` | Produce a self-contained artifact within caller-declared authority.
|
|
177
|
-
| `worker` | Execute bounded work with explicit authority, outputs, and verification.
|
|
178
|
-
| `reviewer` | Perform independent or inherited review exactly as caller policy specifies.
|
|
179
|
-
| `coordinator` | Coordinate a caller-defined topology without taking over caller synthesis or user dialogue.
|
|
185
|
+
| Class | Default contract |
|
|
186
|
+
| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
187
|
+
| `recon` | Read-only, bounded evidence collection. Meet any supplied `task_class` / `model_class_floor` at or above the floor; select an explicit economical target only when no task-class floor was supplied. Never silently inherit a root model. |
|
|
188
|
+
| `dossier-lead` | Reconcile dispersed evidence within one declared scope. May coordinate bounded recon only when nesting is supported and approved. |
|
|
189
|
+
| `generator` | Produce a self-contained artifact within caller-declared authority. |
|
|
190
|
+
| `worker` | Execute bounded work with explicit authority, outputs, and verification. |
|
|
191
|
+
| `reviewer` | Perform independent or inherited review exactly as caller policy specifies. |
|
|
192
|
+
| `coordinator` | Coordinate a caller-defined topology without taking over caller synthesis or user dialogue. |
|
|
180
193
|
|
|
181
194
|
Use stronger workers when context, ambiguity, or consequence requires them,
|
|
182
195
|
not merely because many files exist. Keep coherence-critical synthesis and
|
|
183
196
|
cross-scope judgment in the root caller.
|
|
184
197
|
|
|
198
|
+
## Task Classes and Model Floors
|
|
199
|
+
|
|
200
|
+
Role class and task class are independent. Role class controls authority and
|
|
201
|
+
output ownership; task class is the minimum model-capability floor for one
|
|
202
|
+
bounded objective. A `role.class: recon` worker remains read-only and advisory
|
|
203
|
+
at every task class.
|
|
204
|
+
|
|
205
|
+
Classify by deterministic verifiability, silent-miss risk, dispersed context,
|
|
206
|
+
ambiguity, and consequence, in that order. File count alone never justifies
|
|
207
|
+
escalation:
|
|
208
|
+
|
|
209
|
+
| Task class | Minimum capability contract |
|
|
210
|
+
| ------------------------ | ------------------------------------------------------------------------------------------------------- |
|
|
211
|
+
| `mechanical-recon` | Deterministic inventories, parity checks, or test/lint/format/build execution whose misses are visible. |
|
|
212
|
+
| `intelligent-recon` | Interpretation, unfamiliar-code auditing, or policy/semantic evidence where a miss could be silent. |
|
|
213
|
+
| `default-implementation` | Retain and reconcile dispersed context inside one independently bounded scope. |
|
|
214
|
+
| `hard-reasoning` | Ambiguity, novelty, architecture analysis, or competing interpretations dominate. |
|
|
215
|
+
| `consequential` | Security, release safety, irreversible impact, adversarial analysis, or expensive failure dominates. |
|
|
216
|
+
|
|
217
|
+
Mechanical workers may execute checks and return exact output. Interpretation
|
|
218
|
+
and policy judgment require a stronger class or stay with the root caller. When
|
|
219
|
+
uncertain between classes, use the stronger floor.
|
|
220
|
+
|
|
221
|
+
For unconstrained legacy recon with no `task_class` supplied, select an
|
|
222
|
+
explicit economical target rather than silently inheriting the root model.
|
|
223
|
+
Class-constrained recon must select a target at or above the supplied
|
|
224
|
+
`model_class_floor`; otherwise set `floor_satisfaction: unsatisfied` and return
|
|
225
|
+
the lane through `caller-inline`. An economical target is not a universal
|
|
226
|
+
baseline for the `recon` role.
|
|
227
|
+
|
|
228
|
+
Resolve current class examples through active user and repository instructions
|
|
229
|
+
first, then the active-provider reference and live catalog, all constrained by
|
|
230
|
+
the supplied policy and ceiling. Provider-reference model names are dated
|
|
231
|
+
examples, not canonical requirements. Select an exact eligible target at or
|
|
232
|
+
above the requested floor; never silently downgrade.
|
|
233
|
+
|
|
185
234
|
## Catalog Evidence
|
|
186
235
|
|
|
187
236
|
A catalog snapshot belongs to one dispatch context. A root native catalog does
|
|
@@ -206,9 +255,11 @@ cannot expose before selection. Record the visibility timing instead.
|
|
|
206
255
|
For every dispatch:
|
|
207
256
|
|
|
208
257
|
1. Validate the caller request and capability state.
|
|
209
|
-
2. Resolve provider, context, role class,
|
|
258
|
+
2. Resolve provider, context, role class, optional task class and model-class
|
|
259
|
+
floor, policy, ceiling, and candidates.
|
|
210
260
|
3. Observe the launching dispatcher's relevant catalogs.
|
|
211
|
-
4. Compute the exact native intersection
|
|
261
|
+
4. Compute the exact native intersection at or above the supplied task-class
|
|
262
|
+
floor, when present.
|
|
212
263
|
5. Prefer an eligible native route. Otherwise select one policy-resolved or
|
|
213
264
|
explicitly authorized inherited, provider-CLI/programmatic, workflow, gate,
|
|
214
265
|
or blocked route before launch.
|
|
@@ -239,14 +290,38 @@ flowchart TD
|
|
|
239
290
|
|
|
240
291
|
## Homogeneous Recon Waves
|
|
241
292
|
|
|
293
|
+
A homogeneous wave may share one record only when `task_class` and
|
|
294
|
+
`model_class_floor` match in addition to every existing dispatch axis.
|
|
242
295
|
Multiple read-only recon lanes may share one selection record only when all of
|
|
243
296
|
these axes are identical: provider, dispatch context, catalog snapshot,
|
|
244
297
|
selected route, role class, role selector, model, effort, authority, deadline,
|
|
245
|
-
retry limit, and
|
|
246
|
-
acceptance, and outcome.
|
|
298
|
+
retry limit, fallback, `task_class`, and `model_class_floor`. Include a lane
|
|
299
|
+
manifest with lane-specific scope, acceptance, and outcome. A recon-wave record
|
|
300
|
+
repeats the shared `task_class` and `model_class_floor` beside
|
|
301
|
+
`shared_dispatch_record`; lane entries do not redefine them.
|
|
302
|
+
|
|
303
|
+
If any axis differs or either class field does not match, create separate
|
|
304
|
+
records and waves. The record-level scope is the aggregate wave boundary; each
|
|
305
|
+
lane may narrow that boundary.
|
|
306
|
+
|
|
307
|
+
## Class-Constrained Fallback
|
|
308
|
+
|
|
309
|
+
For a request with task-class metadata, record `model_class_floor` equal to
|
|
310
|
+
`task_class` and set `floor_satisfaction` to `satisfied` or `unsatisfied`.
|
|
311
|
+
An unsatisfied floor blocks launch and returns control to the caller; it never
|
|
312
|
+
records a weaker selection as success.
|
|
313
|
+
|
|
314
|
+
Reviewer-local requests use:
|
|
315
|
+
|
|
316
|
+
```yaml
|
|
317
|
+
fallback:
|
|
318
|
+
mode: caller-inline
|
|
319
|
+
allow_below_task_class_floor: false
|
|
320
|
+
```
|
|
247
321
|
|
|
248
|
-
|
|
249
|
-
|
|
322
|
+
Below-floor selection is prohibited. The legacy `explicit-downgrade` fallback
|
|
323
|
+
remains available only to unconstrained callers without task-class metadata or
|
|
324
|
+
a declared class floor.
|
|
250
325
|
|
|
251
326
|
## Acceptance and Recovery
|
|
252
327
|
|
|
@@ -31,6 +31,27 @@ known role from the active contract when a pre-call role list is unavailable,
|
|
|
31
31
|
and record visibility timing. Do not launch a diagnostic child solely to
|
|
32
32
|
satisfy a universal catalog rule.
|
|
33
33
|
|
|
34
|
+
## Task-Class Resolution
|
|
35
|
+
|
|
36
|
+
Apply active user and repository instructions first; they override the dated
|
|
37
|
+
model-family examples in this provider reference. Intersect the resulting
|
|
38
|
+
class guidance with the live native model enum and the supplied policy and
|
|
39
|
+
ceiling. Select one exact accepted alias at or above the requested floor:
|
|
40
|
+
|
|
41
|
+
- `mechanical-recon`: the fastest economical class suitable for deterministic
|
|
42
|
+
inventories, parity, and command execution;
|
|
43
|
+
- `intelligent-recon`: a stronger fast class that can interpret unfamiliar
|
|
44
|
+
code, semantics, and silent-miss-prone evidence;
|
|
45
|
+
- `default-implementation`: a context-retentive implementation class for
|
|
46
|
+
independently bounded dossier work;
|
|
47
|
+
- `hard-reasoning`: a strong reasoning class for ambiguity or architecture;
|
|
48
|
+
- `consequential`: the strongest allowed class for security, release safety,
|
|
49
|
+
irreversible impact, or expensive failure.
|
|
50
|
+
|
|
51
|
+
A stale or unavailable named example requires a newer eligible model meeting
|
|
52
|
+
the same class floor or a route one class up. Selection below the floor is
|
|
53
|
+
prohibited. Record the exact selector and `floor_satisfaction`.
|
|
54
|
+
|
|
34
55
|
## Surface-Aware Selection
|
|
35
56
|
|
|
36
57
|
- Select an exact accepted alias from the native enum for native dispatch.
|
|
@@ -42,6 +42,28 @@ dispersed evidence, and to a stronger reasoning route when ambiguity,
|
|
|
42
42
|
consequence, or adversarial analysis dominates. Do not escalate merely because
|
|
43
43
|
many files must be searched.
|
|
44
44
|
|
|
45
|
+
## Task-Class Resolution
|
|
46
|
+
|
|
47
|
+
Apply active user and repository instructions first; they override the dated
|
|
48
|
+
model-family examples in this provider reference. Intersect that guidance with
|
|
49
|
+
the live model/effort selectors, registered roles, supplied policy and ceiling,
|
|
50
|
+
and requested class floor:
|
|
51
|
+
|
|
52
|
+
- `mechanical-recon`: an economical class and effort suitable for
|
|
53
|
+
deterministic inventories, parity, and command execution;
|
|
54
|
+
- `intelligent-recon`: a stronger fast class for interpretation,
|
|
55
|
+
unfamiliar-code auditing, and silent-miss-prone evidence;
|
|
56
|
+
- `default-implementation`: a context-retentive implementation class for an
|
|
57
|
+
independently bounded dossier;
|
|
58
|
+
- `hard-reasoning`: a strong reasoning class for ambiguity or architecture;
|
|
59
|
+
- `consequential`: the strongest allowed class for security, release safety,
|
|
60
|
+
irreversible impact, or expensive failure.
|
|
61
|
+
|
|
62
|
+
A stale or unavailable named example requires a newer eligible model meeting
|
|
63
|
+
the same class floor or a route one class up. Selection below the floor is
|
|
64
|
+
prohibited. Keep model and reasoning effort as separate recorded axes, and
|
|
65
|
+
record `floor_satisfaction`.
|
|
66
|
+
|
|
45
67
|
Native spawn acceptance is configured-invocation evidence. Missing runtime
|
|
46
68
|
model identity does not invalidate an accepted configured payload.
|
|
47
69
|
|
|
@@ -15,15 +15,37 @@ volatile snapshot, never a durable inventory.
|
|
|
15
15
|
Root and nested catalogs are independent, volatile observations. Equality in
|
|
16
16
|
one run does not establish equality in another run or nesting boundary.
|
|
17
17
|
|
|
18
|
-
##
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
the
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
18
|
+
## Task-Class Resolution
|
|
19
|
+
|
|
20
|
+
Apply active user and repository instructions first; they override the dated
|
|
21
|
+
model-family examples in this provider reference. Intersect that guidance with
|
|
22
|
+
the exact model choices advertised by the dispatcher, the supplied policy and
|
|
23
|
+
ceiling, and the requested class floor:
|
|
24
|
+
|
|
25
|
+
- `mechanical-recon`: the fastest economical class suitable for deterministic
|
|
26
|
+
inventories, parity, and command execution;
|
|
27
|
+
- `intelligent-recon`: a stronger fast class for interpretation,
|
|
28
|
+
unfamiliar-code auditing, and silent-miss-prone evidence;
|
|
29
|
+
- `default-implementation`: a context-retentive implementation class for an
|
|
30
|
+
independently bounded dossier;
|
|
31
|
+
- `hard-reasoning`: a strong reasoning class for ambiguity or architecture;
|
|
32
|
+
- `consequential`: the strongest allowed class for security, release safety,
|
|
33
|
+
irreversible impact, or expensive failure.
|
|
34
|
+
|
|
35
|
+
A stale or unavailable example requires a newer eligible model meeting the
|
|
36
|
+
same class floor or a route one class up. Selection below the floor is
|
|
37
|
+
prohibited.
|
|
38
|
+
|
|
39
|
+
## Outer Lifecycle Native Selection
|
|
40
|
+
|
|
41
|
+
Outer lifecycle implementer and reviewer dispatch uses the exact
|
|
42
|
+
`providers.cursor.dispatchArgs.variant` returned by the lifecycle resolver.
|
|
43
|
+
The resolver maps an opaque flat model ID and owns the bracket-form model pin
|
|
44
|
+
inside the materialized definition; skills never parse, normalize, or
|
|
45
|
+
reconstruct either model string.
|
|
46
|
+
|
|
47
|
+
1. Require a non-empty resolver-returned variant for managed dispatch.
|
|
48
|
+
2. Launch that exact native agent type first.
|
|
27
49
|
3. Treat native launch acceptance plus the complete launcher payload as
|
|
28
50
|
configured-invocation evidence, not observed runtime model identity.
|
|
29
51
|
4. Permit a replacement route only after a recorded pre-start native
|
|
@@ -36,9 +58,34 @@ never parse, normalize, or reconstruct either model string.
|
|
|
36
58
|
7. Record selected variant, mapped target, acceptance, outcome, and runtime
|
|
37
59
|
identity separately.
|
|
38
60
|
|
|
61
|
+
## Reviewer-Local Nested Selection
|
|
62
|
+
|
|
63
|
+
Reviewer-local recon uses `generalPurpose` with an
|
|
64
|
+
`exact-native-model-choice` selector.
|
|
65
|
+
Reviewer-local reconnaissance is a separate nested native surface. It does not
|
|
66
|
+
use the lifecycle resolver because no materialized lifecycle `recon` role
|
|
67
|
+
exists.
|
|
68
|
+
|
|
69
|
+
1. Read the model choices advertised by the nested Task/Subagent dispatcher.
|
|
70
|
+
2. Intersect those advertised model choices with active user and repository
|
|
71
|
+
model-class instructions, this provider reference, the supplied
|
|
72
|
+
policy/ceiling, and the requested `model_class_floor`.
|
|
73
|
+
3. Use the native `generalPurpose` agent type and pass the exact model choice
|
|
74
|
+
advertised by the current nested dispatcher byte-for-byte.
|
|
75
|
+
4. Record the selector as `model_selector` with
|
|
76
|
+
`model_selector_granularity: exact-native-model-choice`.
|
|
77
|
+
5. Treat an omitted model as deliberate parent inheritance only for an
|
|
78
|
+
unconstrained caller whose recorded policy permits inheritance. A
|
|
79
|
+
class-constrained reviewer lane never omits the model.
|
|
80
|
+
|
|
81
|
+
This nested path does not call the lifecycle resolver, parse bracket-form
|
|
82
|
+
model pins, or reconstruct a lifecycle variant. If no exact nested selector
|
|
83
|
+
satisfies the floor, record `floor_satisfaction: unsatisfied` and return the
|
|
84
|
+
lane for caller-inline coverage without launching a weaker worker.
|
|
85
|
+
|
|
39
86
|
Do not infer Cursor IDE behavior from a headless CLI surface. Keep bounded
|
|
40
|
-
recon on economical explicit targets
|
|
41
|
-
|
|
87
|
+
mechanical recon on economical explicit targets. Stronger lanes use a
|
|
88
|
+
floor-satisfying target when advertised or stay with the primary reviewer.
|
|
42
89
|
|
|
43
90
|
## Dispatch Mode and Liveness
|
|
44
91
|
|
|
@@ -63,13 +110,17 @@ verdict.
|
|
|
63
110
|
|
|
64
111
|
## Pre-Start CLI Routes
|
|
65
112
|
|
|
66
|
-
|
|
67
|
-
|
|
113
|
+
Any native mismatch is recorded before launch with the route, reason, and
|
|
114
|
+
candidate set.
|
|
115
|
+
|
|
116
|
+
When exact outer lifecycle role selection rejects the resolver-selected
|
|
117
|
+
variant before launch, or a generic caller's current native intersection is
|
|
118
|
+
unsatisfactory, a caller may use a deliberate pre-start CLI route only when:
|
|
68
119
|
|
|
69
120
|
- the caller's fallback policy allows it;
|
|
70
121
|
- the exact CLI selector exists in the account catalog;
|
|
71
|
-
- the native mismatch, rejected variant, route, reason, and
|
|
72
|
-
recorded before launch;
|
|
122
|
+
- the native mismatch, rejected variant when applicable, route, reason, and
|
|
123
|
+
candidates are recorded before launch;
|
|
73
124
|
- the prompt is self-contained and authority-bounded.
|
|
74
125
|
|
|
75
126
|
Verify current CLI help before use. A typical shape is:
|
|
@@ -37,6 +37,28 @@ escalate_when:
|
|
|
37
37
|
`dispatch_policy` and `dispatch_ceiling` are optional resolved inputs. The
|
|
38
38
|
general engine does not resolve their source.
|
|
39
39
|
|
|
40
|
+
Task-class metadata is also generic-optional. A class-constrained caller adds
|
|
41
|
+
all of these fields; `oat-reviewer` requires them for reviewer-local recon:
|
|
42
|
+
|
|
43
|
+
```yaml
|
|
44
|
+
task_class: intelligent-recon
|
|
45
|
+
classification_source: caller
|
|
46
|
+
classification_reason: >-
|
|
47
|
+
Determining whether semantic tests pin safety boundaries requires
|
|
48
|
+
interpretation, and a silent miss would survive mechanical checks.
|
|
49
|
+
fallback:
|
|
50
|
+
mode: caller-inline
|
|
51
|
+
allow_below_task_class_floor: false
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
`task_class` is one of `mechanical-recon`, `intelligent-recon`,
|
|
55
|
+
`default-implementation`, `hard-reasoning`, or `consequential`.
|
|
56
|
+
`classification_source` is the literal `caller`, and
|
|
57
|
+
`classification_reason` is non-empty. Legacy callers may omit all three and
|
|
58
|
+
retain the original role-based selection and fallback behavior. The legacy
|
|
59
|
+
`explicit-downgrade` example above is valid only for an unconstrained request
|
|
60
|
+
without task-class metadata or a declared class floor.
|
|
61
|
+
|
|
40
62
|
## Record
|
|
41
63
|
|
|
42
64
|
```yaml
|
|
@@ -76,6 +98,41 @@ diagnostics: []
|
|
|
76
98
|
continuation_events: []
|
|
77
99
|
```
|
|
78
100
|
|
|
101
|
+
For a class-constrained dispatch, the record also includes:
|
|
102
|
+
|
|
103
|
+
```yaml
|
|
104
|
+
task_class: intelligent-recon
|
|
105
|
+
model_class_floor: intelligent-recon
|
|
106
|
+
classification_source: caller
|
|
107
|
+
classification_reason: Semantic contract interpretation has silent-miss risk.
|
|
108
|
+
floor_satisfaction: satisfied
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
`model_class_floor` equals the requested `task_class`.
|
|
112
|
+
`floor_satisfaction` is `satisfied` or `unsatisfied`. An unsatisfied floor
|
|
113
|
+
blocks launch and records no weaker selection as success. These five fields
|
|
114
|
+
remain absent when a legacy request omits task-class metadata.
|
|
115
|
+
|
|
116
|
+
For a Cursor reviewer-local request whose advertised nested model choices do
|
|
117
|
+
not satisfy the class floor, record the blocked selection without inventing a
|
|
118
|
+
selector:
|
|
119
|
+
|
|
120
|
+
```yaml
|
|
121
|
+
role_selector: generalPurpose
|
|
122
|
+
model_selector: null
|
|
123
|
+
model_selector_granularity: exact-native-model-choice
|
|
124
|
+
floor_satisfaction: unsatisfied
|
|
125
|
+
fallback:
|
|
126
|
+
mode: caller-inline
|
|
127
|
+
allow_below_task_class_floor: false
|
|
128
|
+
launch_status: blocked-before-start
|
|
129
|
+
child_outcome: caller-inline-completed
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
`exact-native-model-choice` means an exact model choice advertised by the
|
|
133
|
+
current nested dispatcher. It does not imply a stable enum or authorize
|
|
134
|
+
reconstruction of a materialized lifecycle variant.
|
|
135
|
+
|
|
79
136
|
`role_selector` is the exact provider or harness agent-type selector, when that
|
|
80
137
|
surface exists. Preserve opaque selectors byte-for-byte.
|
|
81
138
|
|
|
@@ -98,6 +155,8 @@ selection source.
|
|
|
98
155
|
wave_id: repo-audit-wave-1
|
|
99
156
|
scope: repo:packages/cli
|
|
100
157
|
shared_dispatch_record: dispatch-unique-id
|
|
158
|
+
task_class: intelligent-recon
|
|
159
|
+
model_class_floor: intelligent-recon
|
|
101
160
|
lanes:
|
|
102
161
|
- lane_id: correctness
|
|
103
162
|
scope: packages/cli/src
|
|
@@ -110,5 +169,7 @@ lanes:
|
|
|
110
169
|
```
|
|
111
170
|
|
|
112
171
|
The wave scope is the aggregate boundary. Lane scope may narrow it. Use one
|
|
113
|
-
shared record only when every dispatch axis listed in the main skill
|
|
114
|
-
identical.
|
|
172
|
+
shared record only when every dispatch axis listed in the main skill,
|
|
173
|
+
`task_class`, and `model_class_floor` are identical. Lane entries do not
|
|
174
|
+
redefine the shared class fields. Mixed classes require separate records and
|
|
175
|
+
waves.
|