validate_mutation_boundary: new files inside a pre-existing untracked directory are invisible (false-negative scope check)

[azalio]

Summary

validate_mutation_boundary (.map/scripts/map_step_runner.py) can silently miss brand-new files a subtask creates, when those files land inside a directory that was ALREADY untracked (present but never git added) before the subtask started. The check reports status: "clean"-adjacent results that omit the new file entirely from both expected-satisfaction and unexpected — i.e. a false negative, not just a false positive.

Observed

Repo: azalio/lida-teamleada, branch default, subtask ST-027.

• docs/ existed untracked before ST-027 started (it already held docs/brd-resource-quotas.md from repo discovery, never committed).
• ST-027's Actor created docs/decisions/hc8-contention.md — a file explicitly named in the subtask's affected_files and required by VC1.
• git status --porcelain (without -uall, as invoked by the script) collapses an untracked directory to a single line ?? docs/ regardless of how many files are inside it or how recently they were added.
• The per-subtask baseline snapshot (taken at validate_step('2.2')) had already recorded docs/ as pre-existing/dirty (because of the older brd-resource-quotas.md), so the subtraction step (actual_set - baseline_files) removes the docs/ entry entirely — even though its contents changed (a brand-new file was added inside it).

Result of python3 .map/scripts/map_step_runner.py validate_mutation_boundary default ST-027:

{
  "status": "warning",
  "expected": ["docs/decisions/hc8-contention.md", "internal/bench/hotrow_bench_test.go", "internal/quota/reserve_batch.go", "test/quota/reserve_batch_test.go"],
  "actual": ["go.mod", "internal/bench/", "internal/quota/reserve_batch.go", "test/quota/reserve_batch_test.go"],
  "unexpected": ["go.mod", "internal/bench/"]
}

docs/decisions/hc8-contention.md never appears in actual at all — not as satisfied-expected, not as unexpected. A reviewer relying on this tool's expected vs actual diff to confirm the doc deliverable was created would get no signal either way.

(Separately, internal/bench/ also collapses to the directory name rather than internal/bench/hotrow_bench_test.go for the same git-status-porcelain-without--uall reason — that one at least surfaces as unexpected so a human notices and can verify, but the untracked-dir-with-preexisting-baseline-file case above suppresses the signal completely.)

Expected

A file that is genuinely new (did not exist at the per-subtask baseline snapshot time) should be visible in actual/unexpected/expected-satisfied bookkeeping even when its parent directory was already untracked before the subtask started. Likely fix: use git status --porcelain -uall (or an equivalent that lists individual untracked files, not collapsed directories) when building actual_set, and diff the baseline at file granularity rather than directory-string equality.

Environment

• mapify_version: 3.22.0
• map-framework commit: 6f5902e
• Affected: .map/scripts/map_step_runner.py, function validate_mutation_boundary (git status/diff assembly around line ~13260-13320)

[azalio]

Взял задачу. Исправляю баг с validate_mutation_boundary — переключаю git status --porcelain на --porcelain -uall для корректного отображения файлов внутри неотслеживаемых директорий.

---

Generated by Claude Code

[azalio]

Исправлено в PR #377 (смёрджен). Добавил -uall во все 5 вызовов git status --porcelain в validate_mutation_boundary, record_subtask_baseline, record_scope_baseline, refresh_blueprint_affected_files и _current_subtask_changed_files. Добавил 4 регрессионных теста, покрывающих сценарий из репорта.

---

Generated by Claude Code

[azalio]

Regression: fix from PR #377 not present in shipped mapify_version 3.23.0

Reproduced the exact same false-negative on a different repo/subtask, on a version installed after this issue was closed as fixed.

Repo: azalio/tg_mcp, branch master, subtask ST-001
mapify_version: 3.23.0 (.map/mapify.lock.json)

• tg_core/ and tests/ are pre-existing untracked directories (they already held guarded_sender.py/__init__.py and test_seam_call_graph.py from repo discovery, never git added).
• ST-001's Actor created tg_core/config.py and tests/test_config.py — both explicitly named in the subtask's affected_files.
• python3 .map/scripts/map_step_runner.py validate_mutation_boundary master ST-001:

{
  "status": "warning",
  "expected": [".env.example", "README.md", "pyproject.toml", "tests/test_config.py", "tg_core/config.py"],
  "actual": ["README.md", "env.example"],
  "unexpected": ["env.example"]
}

pyproject.toml, tg_core/config.py, and tests/test_config.py are all genuinely new/modified (confirmed via git status --porcelain showing them as top-level ??/tracked-modified entries) yet none appear in actual — same "invisible, not even flagged unexpected" failure mode as the original report.

Root cause of the regression: the comment thread on this issue says the fix was "added -uall to all 5 git status --porcelain calls in validate_mutation_boundary, record_subtask_baseline, record_scope_baseline, refresh_blueprint_affected_files and _current_subtask_changed_files" (PR #377, merged). But grepping the shipped .map/scripts/map_step_runner.py at mapify_version 3.23.0 for -uall returns zero matches — every git status --porcelain call in those exact 5 functions (validate_mutation_boundary L13141, record_subtask_baseline L12609, record_scope_baseline L13019, refresh_blueprint_affected_files L11690, _current_subtask_changed_files L13459) still invokes plain --porcelain with no -uall flag.

So either the merged fix didn't make it into the templates that mapify init/update installs, or a later change reverted it. Re-opening seems warranted, or a fresh issue tracking "fix regressed / never shipped to installed template" if you'd rather track it separately.