feedback_verify_after_author_via_directory_ls

After writing a batch of files to a NEW directory and BEFORE downstream consumption (PDF generation, commit-staging), run ls -la <dir>/ to verify all expected files are present on the filesystem.

Why: During BATCH π″ Rich-action send pack execution (2026-05-21T07:00-07:30 BST), I authored 4 per-action files via Write tool calls. Each Write returned “File created successfully at: ” via the harness — implying the file landed on disk. At the verification step ~25 minutes later, ls -la per-action/ showed only 1 of 4 files survived: task-4-mishcon-partner-walkthrough.md (the last-written). task-98, task-2, task-3 had vanished from the filesystem despite the harness reporting Write success at the time.

Cause (hypothesised): unclear. Possibilities:

• A hook (pre-commit / pre-tool / post-tool) ran cleanup between Writes
• A parallel session’s filesystem operation collided with my path
• Harness file-state cache reported success but filesystem write was rolled back silently
• The mkdir -p per-action/ I ran earlier somehow recreated the directory mid-execution, wiping it

What worked for recovery: the file CONTENT was still in my context cache (I had authored each file inline before the disappearance). I re-Wrote the 3 missing files from context; all 4 then survived the second Write batch. PDF regeneration + commit succeeded.

How to apply (proposed §13.6 method-7):

After authoring a batch of N files to a NEW directory and BEFORE the next downstream-consuming operation (PDF gen, commit-staging, cross-link verification), run ls -la <dir>/ <dir>/<subdir>/ (or find <dir> -type f | sort) and grep for the expected file names. If any expected file is missing, restore from context cache and Write again BEFORE the downstream operation.

Specifically:

• After Write × N to NEW dir → ls -la <dir>/ BEFORE pandoc / git add / cross-link verification
• After Edit × N to existing files → git diff --stat BEFORE commit-staging (catches edits-not-landed silently)
• After context-mode ctx_execute writes via Bash cat <<EOF >file patterns → ls -la + content checksum

Companion to §13.6 toolkit:

• Method 1: WebFetch / ctx_fetch_and_index (verify external ground-truth)
• Method 2: Playwright MCP (verify JS-rendered SPA ground-truth)
• Method 3: Multi-venv cross-run (verify library determinism)
• Method 4: Multi-language cross-reference (verify multi-jurisdiction substrate)
• Method 5: Post-commit body-content grep-verify (verify operative-body landing vs frontmatter-only)
• Method 6: Post-commit ^### A-NNN anchor grep (verify arch-state amendment-registry body row)
• Method 7 (candidate): Post-Write directory ls -la verify (verify file-disappearance hasn’t silently happened between Write success report + downstream consumption)

Why this is a §13.6 method, not just a hygiene rule: §13 No-Lies requires that authored substrate exists at the moment of claiming it does. The Write tool’s “File created successfully” message is a CLAIM about filesystem state; method 7 is the VERIFICATION COMMAND that proves the claim true at downstream-consumption time. Without method 7, the failure mode is silent: the harness reports success, downstream consumption (PDF gen, commit) proceeds on a partially-missing file set, and the substrate ships with gaps the author doesn’t know about.

Open question: what’s the root cause of the BATCH π″ mid-flight file-disappearance? Hook execution? Parallel-session collision? Harness cache desync? Worth investigation when the next analogous incident surfaces — capture filesystem inotify log + lsof on the dir + hook execution log to triangulate.

Routing: loaded via MEMORY.md index. Fires during autopilot batches that author multiple files in a NEW directory before downstream consumption. Companion to feedback-worktree-isolation-under-concurrent-storm (broader concurrent-storm discipline) + feedback-concurrent-burst-race-condition-count-24h (project-state observation).