knob-naming vocabulary inconsistent across 14 patterndetector window knobs

[trilamsr]

The patterndetector exposes 14 time-bounded knobs across 11 detectors. The shape per knob is consistent (audit landed in PR #388 / closes #367), but the YAML key suffix vocabulary is inconsistent for the same shape:

One-sided lookback knobs (same shape, four different suffixes):

• xid_correlation_window — pattern Make RFC process optional, not gated #6
• hbm_ecc_window — pattern Add NORTHSTARS, RFC-0002, and Q1 MILESTONES #3
• pcie_aer_window — pattern Apply Wave-1 follow-ups: tests, automation, doc-truth #5
• cuda_oom_correlation_window — pattern Tighten developer and PR feedback loops #10
• dataloader_hang_correlation_window — pattern Add AI review + PR-creation gates and lifecycle skills #7
• join_window — pattern ci(deps): bump the gh-actions group with 5 updates #1 (pod_evicted; no pod_evicted_ prefix at all)

Trailing-window-rate knobs (collide with lookback suffix):

• thermal_throttle_window — pattern Wave 1: governance bootstrap (CODEOWNERS, DCO, signing) #4
• ib_link_flap_window — pattern Bump the gh-actions group across 1 directory with 4 updates #2

Operators reading the YAML cannot tell from the key whether a _window knob is a lookback or a trailing-rate window. Both shapes use _window.

Wall-clock freshness knobs (same shape, two different suffixes):

• nccl_hang_threshold — pattern [ci] Sync branch-protection.yml with relaxed review rule #8
• nccl_bootstrap_deadline — pattern [ci] Set required_status_checks_strict: false #9

Proposed convention (for v1.0 knob-migration window)

• Lookback windows: <pattern>_lookback_window
• Trailing-rate windows: <pattern>_rate_window
• Asymmetric windows: <pattern>_backward_window / <pattern>_forward_window (already consistent on pattern Add developer foundation: Git hooks suite, issue templates, editorconfig #11)
• Freshness thresholds: <pattern>_freshness_threshold
• Pattern-anchored prefix mandatory (pod_evicted_lookback_window, not bare join_window).

Why this is filed as a follow-up not a same-PR fix

A YAML knob rename is operator-visible and breaking. It needs:

1. A deprecation period (alias old knob → new knob, warn on use, drop in v1.x).
2. Coordinated documentation across all detector pattern docs.
3. A migration script for operators on existing tracecore deployments.

Land this in a single coordinated v0.x → v1.0 knob-migration PR rather than scattered across patch releases. The current names are not wrong per se — they just don't compose into a vocabulary an operator can predict.

Refs #367 (audit landed in #388, decision documented in docs/patterns/README.md §Correlation-window semantics).

[trilamsr]

Defer to v2.0 — incompatible with #379 bare-name freeze

Walked the 14 inconsistencies against the knob-naming convention block at the top of module/processor/patterndetectorprocessor/config.go (added in #379). Result: 10 of the 14 inconsistencies are bare-name knobs that are explicitly frozen for v1.0-rc1:

Knob	Frozen?	Notes
join_window	yes	bare-name freeze
nccl_hang_threshold	yes	bare-name freeze
xid_correlation_window	yes	bare-name freeze
hbm_ecc_window	yes	bare-name freeze
hbm_ecc_delta_threshold	yes	bare-name freeze
thermal_throttle_window	yes	bare-name freeze
pcie_aer_window	yes	bare-name freeze
ib_link_flap_window	yes	bare-name freeze
cuda_oom_correlation_window	yes	bare-name freeze
nccl_bootstrap_deadline	no	post-wave prefixed
dataloader_hang_correlation_window	no	post-wave prefixed
checkpointer_hang_backward_window	no	post-wave prefixed, already on the asymmetric _backward_window/_forward_window convention
checkpointer_hang_forward_window	no	same

Renaming the 9 bare-name knobs is operator-visible breakage for any pre-v0.4 values.yaml, and the convention comment in config.go (lines 11-17) already commits to nesting them under <pattern>: { <knob>: ... } in v2.0 with a migration helper.

Why a partial rename now would make things worse

If we land just the 2 renamable ones (nccl_bootstrap_deadline → nccl_bootstrap_freshness_threshold, dataloader_hang_correlation_window → dataloader_hang_lookback_window) we end up with:

• xid_correlation_window and cuda_oom_correlation_window (lookback) still using _window
• dataloader_hang_lookback_window (lookback) using the new vocabulary
• Operator predictability gets worse, not better — same shape, three different suffixes instead of two.

This issue's own body says it best: "Land this in a single coordinated v0.x → v1.0 knob-migration PR rather than scattered across patch releases."

Proposal: defer to v2.0 knob-migration milestone

The proper v2.0 PR will need:

1. Nest bare-name knobs under <pattern>: blocks (already committed-to in config.go's convention comment).
2. Adopt the proposed _lookback_window / _rate_window / _freshness_threshold vocabulary in the same pass.
3. Deprecation aliases on the old top-level keys, warn-on-use, drop in v2.x.
4. Migration script + coordinated doc rewrite across all 11 detector pattern docs.

Closing as wontfix-for-v1.0; will reopen under the v2.0 knob-migration milestone.