OthmanAdi/planning-with-files

We have historical recovery measurements, but contributors cannot run the current file-only recovery protocol from a repository clone. docs/evals.md:253 correctly states that the earlier 5.0 versus 13.3-turn result used transcript catchup and has not been re-run for current project-file-only automatic recovery. At docs/evals.md:273, the harness and all 77 raw run directories are described as living in a separate benchmark workspace. The README repeats the measurement limitation at line 728. A small public recovery fixture would let contributors test the current behavior on their own harness and report comparable results. The first contribution can stay under examples/ and docs/, with no hook, installer or dependency changes. Proposed scope: A disposable task with objective checks, an explicit halfway checkpoint, and a recorded phase and next step. Exact setup, interruption, fresh-session and grading commands. Pinned skill commit or release, host version, model, tested OS and invocatio

The Codex opt-out instructions describe a permission response that the registered adapter does not emit. docs/codex.md:142-145 says that with PLANNING_DISABLED=1, PreToolUse still emits its allow decision so tool calls proceed normally. The registered Python entry point .codex/hooks/pre_tool_use.py:13-14 instead returns when the session is disabled. .codex/hooks/codex_hook_adapter.py:196-197 implements that opt-out by returning false from is_session_attached. The Python adapter also deliberately filters ordinary shell allow responses at .codex/hooks/pre_tool_use.py:24-28. I ran the registered Python entry point with PLANNING_DISABLED=1 and a temporary project containing an incomplete plan. The input was a JSON PreToolUse event with the fixture cwd and a session ID. Observed result on current HEAD: {"entry":".codex/hooks/pre_tool_use.py","disabled":true,"rc":0,"stdout":"","stderr":""} The shell helper .codex/hooks/pre-tool-use.sh:6-8 does emit an allow object when called directly, but t

The manual instructions still describe a fallback that the resolver intentionally refuses. In v3.22.0, the manual /plan-goal steps tell the agent to select PLAN_ID, then .active_plan, then the newest named plan, then the root plan. The topic-handoff guide repeats this sequence. The skill's opening instructions correctly require a selector when several live named plans exist. The resolver also refuses ambiguous selection. An agent following the manual fallback could bypass that protection and choose another task. Verified behavior On commit dab9d16: python -m pytest tests/test_resolve_plan_dir.py -q -k multiple_live_plans_refuse_newest_fallback 1 passed, 12 deselected The test creates two named plans, gives one a newer modification time, and confirms that the resolver selects neither without an explicit pin. The implementation should keep this behavior. A useful first contribution Make the manual workflow use the installed resolver with PLAN_ID and PWF_PLAN_ROOT, stopping recovery whe

Problem When several init-session.ps1 "<name>" runs start at the same moment in one project, an occasional run still exits 1 with: Error: the active plan pointer must be a regular file within the project. The check comes from the pointer pre-check in scripts/set-active-plan.ps1 (lines 348 to 352 in v3.20.8), which runs before the replacement loop: $activeItem = Get-Item -LiteralPath $ActiveFile -Force -ErrorAction SilentlyContinue if ($activeItem -and -not (Test-SafeActiveFile)) { Write-Error "Error: the active plan pointer must be a regular file within the project." exit 1 } If another selector is in the middle of File.Replace at that moment, .planning/.active_plan can exist for Get-Item and be gone or unreadable for Test-SafeActiveFile a moment later. init-session.ps1 (lines 368 to 376) retries only the message the active plan pointer became unsafe during replacement, so this failure is final for that init. Measurements Windows 11, Windows PowerShell 5.1 and pwsh 7.6, rounds

Problem Since v3.20.1 (#264, PR #267) the Hermes plugin applies the several-plans rule: two or more selectable named plans without PLAN_ID inject nothing and print the Multiple plans are available notice. The plugin and the shell count differently when a plan directory under .planning/ is a symlink or a junction: inject-plan.sh (skills/planning-with-files/scripts/inject-plan.sh lines 265 to 270) and resolve-plan-dir.sh --check-ambiguity (lines 334 to 349) test [ -f ".planning/<slug>/task_plan.md" ], which follows links, so a linked plan directory counts. count_selectable_plans in .hermes/plugins/planning-with-files/paths.py (line 215) counts through _slug_plan_dir (line 186), which returns None for a link or reparse point, so the same directory does not count. On a tree with one real plan plan-a and a linked plan-b whose target holds a task_plan.md, the shell route reports ambiguity and injects nothing, while Hermes counts one plan and injects plan-a. Hermes errs on the side of not f