pm health flags provenance values pm-cli itself wrote (CLAUDE_CODE_CHILD_SESSION captured as role), with no command to repair them #998

Summary

pm health reports provenance_value_domain_invalid for provenance values that pm-cli itself wrote, and there is no command to repair them. In 2026.8.10 that warning is fatal under --strict-exit, so upgrading 2026.8.7 → 2026.8.10 turns a project's own history into a hard CI failure with no supported remediation.

Across 23 trackers here this affects 1,255 history events.

Root cause: CLAUDE_CODE_CHILD_SESSION is read as the agent role

On 2026.8.7, when the harness resolves to claude-code, provenance capture reads the env var CLAUDE_CODE_CHILD_SESSION as agent_provenance.role. That variable is a boolean flag set by Claude Code meaning "this is a child session" — its value is 1, not a role.

Reproduction (isolated HOME, empty env, nothing but the two variables):

env -i HOME=$H PATH=$PATH CLAUDECODE=1 CLAUDE_CODE_CHILD_SESSION=1 \
  ./node_modules/.bin/pm create --type Task --title x
# -> "role": {"value": "1", "source": "environment"}

It is a straight pass-through of that variable's value, not a coincidence:

Both variables are required: dropping either one yields role: null. CLAUDECODE=1 selects the claude-code harness; CLAUDE_CODE_CHILD_SESSION then supplies the value.

The capture bug is already fixed — on 2026.8.10 and 2026.8.13 the same environment yields {"value": "implementer", "source": "argv"}. This issue is about the data the old versions wrote, which is still on disk and now fails the gate.

The actual problem: a warning with no remediation

Same tracker, same files, three versions:

warnings:
  - "provenance_value_domain_invalid:claude-code:role:single_digit:19"

The remediation_map in the same health payload only covers telemetry_queue_pending:

remediation_map:
  telemetry_queue_pending: "pm health --check-telemetry"

There is no entry for provenance_value_domain_invalid, and no command repairs it. pm history-repair re-anchors drifted hash chains — it does not normalize provenance values, and the streams here are not drifted. So the only route left is hand-editing committed history/*.jsonl, which is exactly what pm exists to prevent, and which risks the hash chain.

Why this bites hard

Every repo pinned at ≤2026.8.7 has been accumulating these values. The moment one bumps to 2026.8.10 — a routine Dependabot PR — CI goes red on data the previous pinned version wrote, and the diff contains nothing related. That is what happened here: a dependency-bump PR failed its health gate while main was green, and the bump was innocent.

2026.8.13 relaxing this to a warning removes the outage but not the corruption: the values are still invalid, still reported, and still unfixable.

Requests

1. A repair path. Something like pm history-repair --normalize-provenance (or a pm provenance repair) that drops or normalizes out-of-domain provenance values and records an audit marker, the way history-repair already does for hash chains.
2. A remediation_map entry for provenance_value_domain_invalid, so the warning names its own fix like telemetry_queue_pending does.
3. Do not let a warning class change severity silently between releases. 8.7 ignored it, 8.10 made it fatal, 8.13 made it a warning — for identical bytes on disk. A gate whose verdict flips with no change to the input is one that measures the tool version rather than the project. If a new validation must be fatal, it needs a repair command shipped in the same release.

Environment

• pm-cli 2026.8.7 / 2026.8.10 / 2026.8.13, Node 22 + 26, Linux
• Reproduced in a scratch pm init project with an isolated HOME, so no local settings are involved.