Update codex start of day files

Author: DavidQ

docs/dev/start_of_day/codex/BUILD_EXECUTION_CHECKLIST.md

@@ -7,15 +7,19 @@ Before writing code:
 - Are roadmap edits limited to bracket states only?
 - Are start_of_day files untouched?
 - Am I limiting reads to target files and immediate dependencies only?
+- On Windows, am I using Node.js or Python for path/rename/ZIP work unless PowerShell is explicitly required?
+- If PowerShell is required, am I using `Join-Path` or `[System.IO.Path]::Combine(...)` instead of interpolation?
 
 Before finishing:
 - Did I keep scope tight?
 - Did I avoid unrelated refactors?
 - Did I avoid opportunistic cleanup outside scope?
 - Did I run only the requested validation or proof?
 - Did I package a repo-structured delta ZIP under `<project folder>/tmp/`?
-- Do not stage ZIP files in `<project folder>/tmp/`
+- Did I verify the ZIP exists at the exact requested path?
+- Did I avoid staging ZIP files in `<project folder>/tmp/`?
 - Did I clearly report what changed?
+- Did I avoid silent retries after parse or shell errors?
 
 ## Enforcement
 If any precondition fails:

docs/dev/start_of_day/codex/CHANGES_SUMMARY.txt

@@ -0,0 +1,8 @@
+CODEx COMMAND CORRECTIONS SUMMARY
+
+Main fixes:
+- Prefer Node.js or Python over PowerShell for Windows path/rename/ZIP tasks
+- Ban PowerShell string interpolation for path construction
+- Require exact ZIP output path under <project folder>/tmp/
+- Treat missing ZIP output as task failure
+- Stop and report on parse errors instead of silently retrying

docs/dev/start_of_day/codex/README.md

@@ -16,3 +16,9 @@ Codex may not create, modify, rename, delete, replace, or add any file in:
 - `docs/dev/start_of_day/codex/`
 
 unless the user explicitly asks for a change to those directories.
+
+## Windows Execution Preference
+On Windows machines:
+- prefer Node.js or Python for file operations, renames, path normalization, and ZIP-related scripting
+- avoid PowerShell for path-building or rename-heavy work unless PowerShell is explicitly required by the BUILD doc
+- when PowerShell is required, follow the PowerShell Safety Rules in `RULES.md`

docs/dev/start_of_day/codex/RULES.md

@@ -33,11 +33,13 @@ Do not:
 - chase speculative improvements
 
 ## ZIP Output Rule
-Codex should always package code/output ZIP files under:
+Codex must package code/output ZIP files under:
 - `<project folder>/tmp/`
 
 Codex must not stage or commit ZIP files from `<project folder>/tmp/`.
 
+A BUILD task is not complete until the required ZIP exists at the exact requested path.
+
 ## Scope Rule
 - one PR purpose only
 - no unrelated edits
@@ -78,7 +80,28 @@ Codex must report:
 - whether engine-core was untouched if expected
 - the ZIP output path under `<project folder>/tmp/`
 
-
+## Windows Command Rule
+On Windows machines:
+- prefer Node.js or Python for file operations, directory normalization, renames, and packaging
+- do not use PowerShell string interpolation for path construction
+- do not use quoted variable interpolation such as `"$var/path"`, `"$base\$child"`, `"${var}/path"`, or nested interpolation for rename-heavy tasks
+- use `path.join(...)` / `path.resolve(...)` in Node.js or `pathlib.Path` / `os.path.join(...)` in Python
+- use PowerShell only when the BUILD doc explicitly requires it or when no safer runtime is available
+
+## PowerShell Safety Rules
+If PowerShell is required:
+- do not build paths with string interpolation
+- use `Join-Path` or `[System.IO.Path]::Combine(...)`
+- stop immediately on parse errors
+- do not silently retry with rewritten commands
+- report the exact failing command shape and the safer replacement
+
+## Execution Output Rule
+Every BUILD execution command must state:
+- exact target files or directories
+- exact validation to run
+- exact ZIP output path under `<project folder>/tmp/`
+- exact failure conditions
 
 ## 🚫 TESTABILITY GATE (NEW — REQUIRED)
 
@@ -102,4 +125,3 @@ DO NOT EXECUTE:
 Instead:
 - Expand the BUILD scope to a vertical slice
 - Or request a corrected BUILD PR with sufficient scope
-

docs/dev/start_of_day/codex/STOP_AND_REPORT.md

@@ -11,8 +11,13 @@ Stop and report instead of improvising if:
 - the BUILD asks for broad repo analysis without exact targets
 - the BUILD mixes multiple objectives
 - the BUILD uses vague language such as "clean up", "improve", or "modernize" without exact scope
+- a Windows shell or PowerShell parse error occurs before execution
+- the exact ZIP output path under `<project folder>/tmp/` is missing from the BUILD execution command
+- the required ZIP cannot be produced at the requested path
 
 Preferred behavior:
 - stop
 - explain exactly what is blocking execution
 - do not expand scope on your own
+- do not silently rerun with a rewritten shell command
+- report the safer command/runtime to use next

docs/dev/start_of_day/codex/WORKFLOW.md

@@ -6,6 +6,7 @@
 3. Read the current BUILD doc.
 4. Implement only that BUILD scope.
 5. Stop immediately if the BUILD doc fails the execution threshold.
+6. Prefer Node.js or Python over PowerShell on Windows for path, rename, and ZIP tasks.
 
 ## During Work
 - open target files first
@@ -15,23 +16,25 @@
 - preserve project-specific ownership
 - avoid speculative expansion
 - avoid opportunistic cleanup/refactor
+- for Windows path work, use explicit path APIs rather than interpolated shell strings
+- if the BUILD requires PowerShell, use `Join-Path` or `[System.IO.Path]::Combine(...)`
 
 ## When Finished
 1. run required validation
 2. report exact files changed
 3. report validation results
 4. package a repo-structured delta ZIP under `<project folder>/tmp/`
 5. do not stage ZIP files from `<project folder>/tmp/`
-6. stop after BUILD output is complete
+6. confirm the ZIP exists at the exact requested path
+7. stop after BUILD output is complete
 
 ## Do Not
 - generate APPLY instructions unless explicitly requested
 - redo planning
 - modify roadmap wording
 - touch start_of_day files
 - continue after a failed execution threshold
-
-
+- silently rerun after a PowerShell parse error
 
 ## ✅ BUILD PR Quality Requirement (TESTABILITY)
 
@@ -45,4 +48,3 @@ Avoid:
 
 Rule of thumb:
 If it cannot be executed or meaningfully validated, it is not a valid BUILD.
-