Fix contract rules.

Author: stephenlienharrell

monitor/cursor-rules/implementation-workflow-discipline.mdc

@@ -22,6 +22,7 @@ Use these during **plan**, **implement**, **self-review**, and **verification**
 | [monitor-collect-tier-gating.mdc](monitor-collect-tier-gating.mdc) | Two-tier collect/emit: `stats_set` gate, daemon phase, SIGHUP slot reset. |
 | [monitor-schema-keys-headers.mdc](monitor-schema-keys-headers.mdc) | Shared `KEYS` headers; contract tests include headers, no macro duplication. |
 | [monitor-consumer-schema-migration.mdc](monitor-consumer-schema-migration.mdc) | Breaking output: rename map, README rollout, contract tests. |
+| [monitor-consumer-side-plan.mdc](monitor-consumer-side-plan.mdc) | Monitor changes needing consumer work: secondary plan (what + why) before/during implement. |
 | [monitor-debug-shm.mdc](monitor-debug-shm.mdc) | DEBUG `/dev/shm` mirror: permissions, gating, tests. |
 | [monitor-ib-sysfs-parsing.mdc](monitor-ib-sysfs-parsing.mdc) | IB port state parsers; inactive/active substring traps. |
 | [monitor-ci-workflow.mdc](monitor-ci-workflow.mdc) | GitHub `monitor-verify.yaml` vs local dual-verify. |
@@ -45,6 +46,8 @@ Break the problem down step-by-step. In the response (or in thinking for trivial
 
 Only after this breakdown, implement. Skip the written plan only for truly trivial edits (typo, comment-only) where the change is obvious and risk-free.
 
+If the monitor plan implies consumer changes, add the **Consumer follow-up plan** section per **monitor-consumer-side-plan** (even when implementing monitor-only in this session).
+
 ## 3. Implement
 
 Write the code. Match existing conventions in the touched files and the **Related rules** above — at minimum [monitor-c-conventions.mdc](monitor-c-conventions.mdc) for monitor C, [traceback-fix-discipline.mdc](traceback-fix-discipline.mdc) for error-driven fixes, and [monitor-workspace-contract.mdc](monitor-workspace-contract.mdc) for scope and consumer contracts.

monitor/cursor-rules/monitor-consumer-schema-migration.mdc

@@ -26,7 +26,7 @@ Any change that breaks **historical** ingest or queries:
    - `removed_legacy:` for retired typenames/keys
 2. **`monitor/README.md`** — migration table or rollout note (deploy monitor + consumer together when needed).
 3. **Contract tests** — `test_*_schema_contract.c` or golden tests for new shape.
-4. Call out if **`listend.py`** / **`sync_timedb_parsing.py`** need a separate authorized consumer edit (**monitor-workspace-contract**).
+4. **Consumer secondary plan** — structured what/why/rollout/verify section per **monitor-consumer-side-plan** (implementation still requires explicit user authorization).
 
 ## Two-tier rollout
 

monitor/cursor-rules/monitor-consumer-side-plan.mdc

@@ -0,0 +1,35 @@
+---
+description: When monitor output changes need consumer work, produce a secondary consumer plan (what + why)
+alwaysApply: true
+---
+
+# Monitor: consumer-side secondary plan
+
+When a **monitor** change would require updates outside `HPCPerfStats/monitor/` (ingest, dbload, analysis, dashboards), produce a **secondary consumer plan** in the same turn — **before** or **alongside** monitor implementation. Do **not** implement consumer code unless the user explicitly authorizes that path (**monitor-workspace-contract**, **out-of-monitor-hpcperfstats-rules**).
+
+## Trigger (any of these)
+
+- New or changed sample/schema shape (`@fast`/`@full`, `,R=S`, column count, host token position).
+- `st_name`, device id, or event key rename/retirement that breaks historical ingest or queries.
+- Semantics change (gauge vs cumulative `E`, MAD vs sysfs counter source).
+- Consumer parser would mis-align, drop, or mis-label columns without a matching change.
+
+Read **`HPCPerfStats/hpcperfstats/listend.py`** (and relevant parsers such as **`sync_timedb_parsing.py`**) to confirm impact — do not guess.
+
+## Required secondary plan content
+
+Use a clearly labeled section, e.g. **Consumer follow-up plan**, with:
+
+1. **Why** — what monitor behavior changed and why the current consumer cannot handle it.
+2. **What** — concrete tasks (files/functions/tests) on the consumer side.
+3. **Rollout** — deploy order (consumer first vs together vs monitor escape hatch e.g. `enable_slow_tier 0`).
+4. **Verification** — consumer tests or manual checks to run after both sides land.
+5. **Rename/migration** — YAML map entries, dashboard/query updates if applicable (**monitor-consumer-schema-migration**).
+
+Keep the plan actionable for a separate session or authorized consumer edit; it is not a substitute for **`monitor_variable_rename_map.yaml`** or **`monitor/README.md`** migration notes when those apply.
+
+## Monitor-only handoff
+
+In the monitor implementation summary, state explicitly: **consumer plan attached** or **no consumer changes required**, with one sentence of rationale.
+
+Cross-links: **monitor-workspace-contract**, **monitor-consumer-schema-migration**, **implementation-workflow-discipline**.

monitor/cursor-rules/monitor-workspace-contract.mdc

@@ -30,7 +30,7 @@ alwaysApply: true
 ## Change Validation Expectation
 
 - For monitor-side message format changes, validate compatibility against `listend.py` parsing logic before finalizing edits.
-- If a monitor change would require consumer changes, stop and call out the contract break clearly.
+- If a monitor change would require consumer changes, produce a **secondary consumer plan** (what + why) per **monitor-consumer-side-plan** — do not only mention a vague “contract break.”
 
 ## Precedence and overrides