[self-repair:1aa8b5010178] [orchestrator-defect] Lock hash ignores legacy scope and gate labels accepted by parsePlan

[srnichols]

Class

orchestrator-defect

Symptom

Read-only reproduction on Rummag Phase 129: parsePlan recognizes all 15 slices and the actual validationGate commands under Validation Gate:. Editing the S3/S4 commands leaves computeLockHash byte-identical (1e6fd86472b827bd50e812225041cfa56289d4503ff8c6ba98585d6a4975f4f0). computeLockHash only recognizes Validation Gate: and Scope (files in scope):, so accepted legacy Scope (files in scope): and Validation Gate: declarations are outside lock coverage. A successful parse and an unchanged hash falsely appear to protect executable commands.

Workaround Applied

Normalized only the two actively completed slices to the canonical labels, retained the other 13 slices byte-identical, documented the limitation for remaining legacy slices, and proved two in-memory gate mutations change the new hash (8e80f0f8a25b127d8a6bd49a51a65be3291ad126d931590f2a626af92b2cf032). Shared parser source was not modified. Recommended durable fix: share scope/gate marker recognition between parser and hash scanner, with negative controls for every accepted spelling.

Files

• pforge-mcp/orchestrator/plan-parser.mjs
• docs/plans/Phase-129-LIVE-MONEY-OBSERVABILITY-PLAN.md

Reference

Plan: docs/plans/Phase-129-LIVE-MONEY-OBSERVABILITY-PLAN.md

[srnichols]

Fixed in da478848. The lock hash covers exactly the lines the parser turns into slice scopes and gates, including non-canonical labels such as **Validation Gate:** and **Files**:. Canonical plans keep their hash. Plans with previously uncovered lines get a new one, and the LOCK_HASH_MISMATCH message explains why.

Available on planning/main now. It reaches projects with the next release, through pforge self-update or pforge update.

[srnichols]

Released in v3.27.0. Projects pick it up with pforge self-update (see the release's upgrade notes for Git Bash).