/map-plan: add a 'verify live/runtime state' discovery step when the plan depends on production data

[azalio]

Summary

/map-plan Step 0 (Quick Discovery) + Step 0.5 (Already-Implemented Gate) only inspect the static repo (code, migrations, file:line). When a plan's correctness rests on live/runtime state — production row counts, enum values actually present in a prod DB, columns that already exist, the applied migration head, a live feature-flag value — the skill never prompts the planner to go verify that empirically. So the plan is built on assumptions copied from design docs / memory notes, and those assumptions silently drift from reality.

Observed

Planning Epic #244 Slice 0 (a destructive-class DB migration on a ~21k-row prod corpus) with /map-plan, I produced a fully-validated spec + blueprint whose ST-002/ST-003/ST-006 rested entirely on prod-state numbers taken from the issue/design doc. The skill never suggested checking prod. Only when the operator explicitly asked ("сходи на прод и проверь") did I run read-only psql against the live DB — and found plan-affecting drift the static discovery could not have caught:

• type is an enum with 16 labels incl. USER_ATTRIBUTE, but the Go enum declares only 15 (Go↔DB drift) → abort-on-unmapped mapping had to enumerate from pg_enum, not the Go constants.
• status is enum item_status with 6 values → an item_status→lifecycle_status mapping the plan had left implicit.
• priority column already exists → migration must ADD IF NOT EXISTS and not overwrite.
• validated_rule=0 / consolidation_candidate=0 live → confirmed an acceptance criterion empirically.
• Counts drifted up (~88 rows/day firehose): total 20,995→21,307, lookup-RULE ~1,376→1,473 → migration must capture counts live, not hardcode.

None of this is reachable by reading the repo; it required touching the running system. The methodology had no step that made me do it.

Expected

When workflow-fit / discovery detects that the plan depends on runtime/production state (signals: a DB migration, a data backfill, "measured on prod" numbers in the source, count-based acceptance criteria, feature-flag cutover, capacity/perf assumptions), /map-plan should add an explicit "Verify live state" discovery step that:

• prompts the planner to empirically check the assumptions the plan rests on (read-only), or
• if prod is unreachable, records the unverified assumptions as Open Questions / Risks with the exact check to run — instead of silently baking them in.

This is the runtime analogue of the existing Already-Implemented gate: that gate stops you re-planning code that already exists; this one stops you planning against runtime facts that have drifted. Could be a sub-case of Step 0.5 or a new Step 0.6 gated on a depends_on_runtime_state signal in record_workflow_fit.

Environment

• mapify_version: 3.17.1
• Affected: /map-plan SKILL — Step 0 "Quick Discovery" and Step 0.5 "Already-Implemented Gate" (no live/runtime verification step); related: record_workflow_fit signals (no depends_on_runtime_state).