Enforce orchestrator-side metadata.variety stamp on Task B dispatches (currently advisory-only)

[michael-wojcik]

Context

The orchestrator's Teachback-Gated Dispatch (persona §11) requires the lead to stamp metadata.variety — the D11 4-rationale shape (total + novelty_rationale / scope_rationale / uncertainty_rationale / risk_rationale) — on every Task B (work) dispatch. This stamp is currently advisory-only: hooks/task_lifecycle_gate.py emits variety_missing_on_dispatch / variety_band_unresolvable as PostToolUse advisories that fire AFTER the teammate is already dispatched and has begun its teachback. Nothing prevents — or strongly catches at the right boundary — the lead omitting the stamp.

Empirical anchor (session pact-c69b1cf9, 2026-05-28)

During a /PACT:plan-mode consultation, 4 of 4 Task B dispatches went out without a metadata.variety stamp. Consequences observed:

• 3 of 4 consultants returned variety_acknowledgment.rationale_articulates_this_dispatch = "concern", each noting "no orchestrator per-dimension rationale to judge against."
• The lifecycle gate emitted variety_missing_on_dispatch — but only after dispatch, as a soft signal.
• Recovery required an orchestrator-side correction: re-stamp all four Task B tasks, then accept the teachbacks. The omission was caught only reactively, via the teammates' concern flags.

This is a recurring foot-gun: the stamp is a manual step buried in the D11 convention, easy to skip, and the only feedback is late and soft.

Why it matters

The Task B metadata.variety stamp drives three downstream determinations:

1. Concurrent-auditor trigger (total >= 7 → mandatory auditor on CODE).
2. reasoning_reconstruction band (_resolve_required_band_via_blocks: total >= 11 → required; 7–10 → recommended; <= 6 → skipped).
3. Workflow route (route_workflow).

An unstamped Task B makes all three unresolvable — _resolve_required_band_via_blocks returns "unresolvable" and fails open. The teammate's reasoning_reconstruction obligation can't be determined at teachback-submit time, so the L1.5 method-level gate degrades silently.

Proposed enforcement (options for the implementer to weigh)

1. Pre-dispatch boundary enforcement (preferred direction). Add a gate that DENIES (or strongly warns at PreToolUse) when a Task B is wired into a teachback-gated dispatch without a well-formed metadata.variety. Analogous to the teammate-side teachback_gate blocking flip (Phase 2: flip teachback_gate to blocking mode (follow-up to #401) #481).
   • CRITICAL timing constraint (FIRST-OBSERVABLE-WRITE lesson, pin task_lifecycle_gate teachback_addblocks_missing fires at TaskCreate(A) before Task B exists (unsatisfiable check) #843 / memory 39eb6423): enforce at the TERMINAL wiring write — the TaskUpdate that sets owner + addBlockedBy/addBlocks linking A↔B, or the Agent(...) spawn — NOT at the initial TaskCreate(B), where variety legitimately may not be set yet. Enforcing at first-write would be unsatisfiable-by-construction (the same class as the task_lifecycle_gate teachback_addblocks_missing fires at TaskCreate(A) before Task B exists (unsatisfiable check) #843 misfire).
2. Strengthen the advisory. Make variety_missing_on_dispatch name the exact missing fields and emit a copy-paste re-stamp recipe, and ensure it surfaces prominently at the dispatch boundary rather than after the teammate has begun.
3. Persona/skill reinforcement. Add an explicit "stamp metadata.variety on Task B BEFORE spawn" step to the §11 dispatch sequence checklist (currently implied via D11, not a hard ordered step). Composite (doc + write-time advisory) per the LLM-error-mode-defense pin.

Relationship to existing issues

• Distinct from Codify variety-tiered blocking teachback using variety_scorer.py as backbone #401 / Phase 2: flip teachback_gate to blocking mode (follow-up to #401) #481 — those enforce the teammate-side teachback gate (block Edit/Write without a valid teachback). This issue is the orchestrator-side dispatch-time stamp-presence requirement.
• Distinct from Cross-session calibration for D10/D11 absolute-score-skew (Learning II hardening) #838 — that addresses D10/D11 score-skew calibration (is the number right?); this addresses stamp presence (is there a number at all?).
• Composes with the variety_band_unresolvable advisory already in task_lifecycle_gate.py (_resolve_required_band_via_blocks "unresolvable" path) — that surface is the natural home for a strengthened/blocking variant.

Acceptance criteria (draft)

• A lead omitting metadata.variety on a teachback-gated Task B is caught at the dispatch boundary (terminal wiring write or spawn), not after the teammate begins.
• Enforcement does NOT misfire at TaskCreate(B) (FIRST-OBSERVABLE-WRITE invariant preserved).
• The signal names the missing fields and the fix.
• Structural test pins the enforcement boundary + the no-misfire-at-TaskCreate invariant.

---

Surfaced empirically while re-evaluating #864 (cron-machinery removal) under /PACT:plan-mode.

[michael-wojcik]

Second /PACT:plan-mode repro + template-parity root cause (2026-06-01)

Repro (session 6f81f147 → resumed 9d09a19a, 2026-06-01). A /PACT:plan-mode consultation for the Family E dormancy fix (#806 Item 3) dispatched 5 consultants (preparer / architect / devops / test-engineer / security). All 5 Task B (consultation) dispatches went out without a metadata.variety stamp — the same signature as this issue's 2026-05-28 anchor:

• 2 of 5 consultants returned variety_acknowledgment.rationale_articulates_this_dispatch = "concern" (preparer, security), each noting "no per-dimension rationale to judge against." The other 3 flagged the missing stamp informationally and self-elected to include reasoning_reconstruction defensively.
• task_lifecycle_gate emitted variety_missing_on_dispatch_task + reasoning_reconstruction_band_unresolvable — after dispatch, as soft signals (exactly as this issue describes).
• Recovery was again an orchestrator-side re-stamp of all 5 Task B tasks (variety 10–13, per-dimension rationales), then teachback acceptance.

The foot-gun has now reproduced twice, both times under /PACT:plan-mode — which points at a specific root cause the issue body doesn't yet name.

Template-parity root cause (verified). plan-mode.md is the only dispatch skill whose Task B TaskCreate template omits the metadata.variety block. Marker count via grep -c 'novelty_rationale\|"variety"':

skill	variety-block markers
commands/plan-mode.md	0
commands/orchestrate.md	5
skills/comPACT/SKILL.md	6
commands/peer-review.md	4

A lead following plan-mode.md verbatim produces unstamped consultation tasks; the other three skills carry the variety block inline in their Task B TaskCreate, which prompts the stamp. That asymmetry is almost certainly why the omission recurs specifically in plan-mode (both the 2026-05-28 anchor and the 2026-06-01 repro were plan-mode sessions).

Proposed enforcement option 4 (low-cost, addresses the root cause):

4. plan-mode.md Task-B template parity. Add the same D11 4-rationale metadata.variety block to plan-mode.md's Teachback-Gated Dispatch Task B TaskCreate template that orchestrate.md / comPACT / peer-review.md already carry. Documentation/template-only; no hook change. Closes the recurring plan-mode-specific instance at its source, and is independent of (and complementary to) the heavier pre-dispatch boundary gate (option 1).

Note: if the project instead decides plan-mode consultation tasks should be variety-exempt (they are read-mostly analysis), the alternative is to exempt them in task_lifecycle_gate rather than stamp them. Parity is the simpler choice and it keeps the reasoning_reconstruction band resolvable for plan-mode — plan-mode tasks are frequently ≥ 11 (→ ROUTE_PLAN_MODE → reconstruction required), which is exactly where the L1.5 method-gate adds value.

[michael-wojcik]

Fourth /PACT:plan-mode repro (2026-06-16, v4.4.25) + new finding: the teammate-side "concern" backstop is leaky

Same signature as the 2026-05-28 anchor and the 2026-06-01 repro. Session pact-d7536582, plugin v4.4.25, /PACT:plan-mode, 4 consultants (preparer / architect / devops / test). All 4 Task B dispatches went out with no metadata.variety; the variety_band_unresolvable advisory fired post-dispatch; recovery was an orchestrator-side re-stamp of all four before accepting teachbacks.

New sub-finding — the reactive backstop is unreliable. The current "feedback" is teammates flagging variety_acknowledgment.rationale_articulates_this_dispatch = "concern". This session only 2 of 4 flagged it (devops, test); the other 2 (preparer, architect) returned "yes" despite the identical missing stamp — they judged the dispatch articulable from its prose scope and moved on. So the concern-flag is a leaky detector: it fires often enough to notice but not reliably enough to be a backstop. You cannot count on the teammate to catch the lead's omission — which removes the main argument against hard pre-dispatch enforcement.

This strengthens the Option 1 (pre-dispatch boundary enforcement) direction: deny / strong-warn at PreToolUse when a Task B is wired into a teachback-gated dispatch without a well-formed metadata.variety, since the only current catch (the teammate concern flag) demonstrably misses ~half the time. The plan-mode-specific upstream cause (template omits the stamp entirely) is #891.

[michael-wojcik]

Closed by #1029 (merged 53e4a65, v4.4.41). Deterministic dispatch-boundary enforcement landed and verified live: the gate fires on genuinely-unstamped dispatches via is_pact_specialist_owner agentType resolution — mutation-proven (reverting to the dead owner.startswith('pact-') predicate REDs the deny-honor probe). Default WARN; env-gated DENY (PACT_DISPATCH_VARIETY_MODE) is opt-in, source-proven, fail-safe. The optional deny-honor live-config round-trip probe is tracked as #1030.