Umbrella: per-dispatch variety-stamp completeness — enforce (#865) + plan-mode template (#891) + feature-task extension (#873)

[michael-wojcik]

Umbrella

Groups three open, tightly-coupled issues that together close the "every dispatch/task carries a resolvable metadata.variety stamp" gap. They share the same subsystem (hooks/task_lifecycle_gate.py variety handling + the dispatch-command Task-B templates) and have interacting designs, so they should be designed and implemented as one work-unit rather than three overlapping PRs.

Tracked issues

• Enforce orchestrator-side metadata.variety stamp on Task B dispatches (currently advisory-only) #865 — Enforce orchestrator-side metadata.variety stamp on Task B dispatches (currently advisory-only). The enforcement gate: catch a missing Task-B stamp at the dispatch boundary (terminal A↔B wiring write or Agent spawn), not after the teammate begins. Carries a CRITICAL timing constraint (FIRST-OBSERVABLE-WRITE: enforce at the terminal wiring write / spawn, not at TaskCreate(B), which would be unsatisfiable-by-construction).
• plan-mode consultation Task B omits per-dispatch variety stamp → reasoning_reconstruction band unresolvable #891 — plan-mode consultation Task B omits per-dispatch variety stamp. The most common cause of the omission Enforce orchestrator-side metadata.variety stamp on Task B dispatches (currently advisory-only) #865 exists to catch — the plan-mode.md consultation Task-B template lacks the metadata.variety block that orchestrate.md / comPACT.md / peer-review.md include.
• Extend variety-stamp enforcement to umbrella/feature tasks (for computable feature-vs-dispatch divergence) #873 — Extend variety-stamp enforcement to umbrella/feature tasks. Apply the same stamping/enforcement to the feature/umbrella task layer so the wrap-up Q5 divergence computation has both halves (feature variety + per-dispatch distribution).

The pivotal coupled decision (settle once, across all three)

#891 offers two fixes whose choice changes what #865's gate enforces:

• Option 1 — hardcode a metadata.variety block in the plan-mode consultation Task-B template (pure template edit).
• Option 2 — the band resolver (_resolve_required_band_via_blocks) inherits the parent Plan task's metadata.variety.total when Task B has none.

#891's own evidence (3rd recurrence comment) argues Option 2: consultation Task-Bs scored 11–13, not the assumed ~7–10, so a hardcoded-low stamp would mis-resolve the reasoning_reconstruction band and wrongly mark it not required. Whichever is chosen, #865's gate must agree on whether "unstamped" stays unresolvable or legitimately inherits — and #873 extends whatever gate #865 builds. That coupling is the reason to batch: one resolver/enforcement design, not three.

Recommended approach

Run /PACT:plan-mode on the batch to settle (a) Option 1 vs Option 2, (b) #865's enforcement boundary + the FIRST-OBSERVABLE-WRITE no-misfire-at-TaskCreate invariant, (c) the #873 feature-task extension — then one coherent implementation + test surface across task_lifecycle_gate and the dispatch templates.

Recurrence note

The plan-mode omission (#891) has reproduced repeatedly across plugin versions — filed 2026-06-02, calibration memory 2026-06-07, recurred 2026-06-16 (v4.4.25), and again 2026-06-24 during the #1023 fix's plan-mode consultation (the Task-B's were stamped reactively after a consultant flagged the gap; this drove the wrap-up Q6 27% variety-acknowledgment concern rate). It stays a live foot-gun because the stamp is advisory-only (#865).

---

Does NOT auto-close #865 / #873 / #891 — this umbrella groups + sequences them; each closes when its surface lands (likely via one batched PR).

[michael-wojcik]

Umbrella closed by #1029 (v4.4.41). All three surfaces dispositioned: #865 (deterministic boundary WARN + env-gated deny), #891 (template parity + resolver-inherit fail-safe), #873 (feature-stamp). Fresh verify-only round 4/4 clean; full suite 9567 passed / 0 errors. Optional deny-honor live-probe tracked as #1030.