starred/planning-with-files

Fork 0

mirror of https://github.com/OthmanAdi/planning-with-files.git synced 2026-04-25 16:06:02 +03:00

[GH-ISSUE #78] session-catchup false positive in skill-distributed copies (not root script) #48

New issue

Closed

opened 2026-03-03 18:50:15 +03:00 by kerem · 2 comments

kerem commented

2026-03-03 18:50:15 +03:00

Owner

Originally created by @gydx6 on GitHub (Feb 15, 2026).
Original GitHub issue: https://github.com/OthmanAdi/planning-with-files/issues/78

Summary

False positive catchup occurs in skill-distributed copies of session-catchup.py.

Affected scope

Affected (skill-distributed copies):
- .adal/skills/planning-with-files/scripts/session-catchup.py
- .codebuddy/skills/planning-with-files/scripts/session-catchup.py
- .codex/skills/planning-with-files/scripts/session-catchup.py
- .continue/skills/planning-with-files/scripts/session-catchup.py
- .gemini/skills/planning-with-files/scripts/session-catchup.py
- .openclaw/skills/planning-with-files/scripts/session-catchup.py
- .opencode/skills/planning-with-files/scripts/session-catchup.py
- .pi/skills/planning-with-files/scripts/session-catchup.py
- skills/planning-with-files/scripts/session-catchup.py
Not affected: scripts/session-catchup.py (root script has early-return behavior)

Why this is a bug

In affected skill copies, has_planning_files is computed in main() but not used to gate behavior. When no planning update is found, the script falls back to recent messages and still prints unsynced context.

This can produce false positives and inject unrelated context into a fresh session.

Reproduction

Use a project directory that does not contain task_plan.md, findings.md, or progress.md.
Ensure there is a prior substantial session history under Claude/Codex project storage.

Run the command exactly as documented in SKILL.md:

$(command -v python3 || command -v python) ~/.codex/skills/planning-with-files/scripts/session-catchup.py "$(pwd)"

Observe output includes:
- [planning-with-files] SESSION CATCHUP DETECTED
- No planning file updates found in previous session
- --- UNSYNCED CONTEXT ---

Expected behavior

If no planning files exist, or no planning update exists, the script should exit silently (no catchup report).

Actual behavior

Catchup report is emitted from non-planning context.

Suggested fix

Either approach is fine:

Early return when has_planning_files is false.
Early return when no planning update is found (last_update_line < 0), aligning behavior with root scripts/session-catchup.py.

Originally created by @gydx6 on GitHub (Feb 15, 2026). Original GitHub issue: https://github.com/OthmanAdi/planning-with-files/issues/78 ## Summary False positive catchup occurs in skill-distributed copies of `session-catchup.py`. ## Affected scope - Affected (skill-distributed copies): - `.adal/skills/planning-with-files/scripts/session-catchup.py` - `.codebuddy/skills/planning-with-files/scripts/session-catchup.py` - `.codex/skills/planning-with-files/scripts/session-catchup.py` - `.continue/skills/planning-with-files/scripts/session-catchup.py` - `.gemini/skills/planning-with-files/scripts/session-catchup.py` - `.openclaw/skills/planning-with-files/scripts/session-catchup.py` - `.opencode/skills/planning-with-files/scripts/session-catchup.py` - `.pi/skills/planning-with-files/scripts/session-catchup.py` - `skills/planning-with-files/scripts/session-catchup.py` - Not affected: `scripts/session-catchup.py` (root script has early-return behavior) ## Why this is a bug In affected skill copies, `has_planning_files` is computed in `main()` but not used to gate behavior. When no planning update is found, the script falls back to recent messages and still prints unsynced context. This can produce false positives and inject unrelated context into a fresh session. ## Reproduction 1. Use a project directory that does **not** contain `task_plan.md`, `findings.md`, or `progress.md`. 2. Ensure there is a prior substantial session history under Claude/Codex project storage. 3. Run the command exactly as documented in `SKILL.md`: ```bash $(command -v python3 || command -v python) ~/.codex/skills/planning-with-files/scripts/session-catchup.py "$(pwd)" ``` 4. Observe output includes: - `[planning-with-files] SESSION CATCHUP DETECTED` - `No planning file updates found in previous session` - `--- UNSYNCED CONTEXT ---` ## Expected behavior If no planning files exist, or no planning update exists, the script should exit silently (no catchup report). ## Actual behavior Catchup report is emitted from non-planning context. ## Suggested fix Either approach is fine: 1. Early return when `has_planning_files` is false. 2. Early return when no planning update is found (`last_update_line < 0`), aligning behavior with root `scripts/session-catchup.py`.

kerem

2026-03-03 18:50:15 +03:00

closed this issue
added the
bug
label

kerem commented

2026-03-03 18:50:16 +03:00

Author

Owner

@gydx6 commented on GitHub (Feb 15, 2026):

Additional verification: this is a script-copy sync issue (copy drift), not only a single-path bug.

I checked all session-catchup.py copies in the repo tree. The same false-positive behavior is present in multiple skill-copy paths, including:

.adal/skills/planning-with-files/scripts/session-catchup.py
.codebuddy/skills/planning-with-files/scripts/session-catchup.py
.codex/skills/planning-with-files/scripts/session-catchup.py
.continue/skills/planning-with-files/scripts/session-catchup.py
.gemini/skills/planning-with-files/scripts/session-catchup.py
.openclaw/skills/planning-with-files/scripts/session-catchup.py
.opencode/skills/planning-with-files/scripts/session-catchup.py
.pi/skills/planning-with-files/scripts/session-catchup.py
skills/planning-with-files/scripts/session-catchup.py

By contrast, root scripts/session-catchup.py uses a different early-return flow and does not show this specific behavior.

So the fix likely needs to be applied consistently across generated/distributed script copies, and ideally enforced by a single source-of-truth or sync check in CI.

@gydx6 commented on GitHub (Feb 15, 2026): Additional verification: this is a script-copy sync issue (copy drift), not only a single-path bug. I checked all `session-catchup.py` copies in the repo tree. The same false-positive behavior is present in multiple skill-copy paths, including: - `.adal/skills/planning-with-files/scripts/session-catchup.py` - `.codebuddy/skills/planning-with-files/scripts/session-catchup.py` - `.codex/skills/planning-with-files/scripts/session-catchup.py` - `.continue/skills/planning-with-files/scripts/session-catchup.py` - `.gemini/skills/planning-with-files/scripts/session-catchup.py` - `.openclaw/skills/planning-with-files/scripts/session-catchup.py` - `.opencode/skills/planning-with-files/scripts/session-catchup.py` - `.pi/skills/planning-with-files/scripts/session-catchup.py` - `skills/planning-with-files/scripts/session-catchup.py` By contrast, root `scripts/session-catchup.py` uses a different early-return flow and does not show this specific behavior. So the fix likely needs to be applied consistently across generated/distributed script copies, and ideally enforced by a single source-of-truth or sync check in CI.

kerem commented

2026-03-03 18:50:16 +03:00

Author

Owner

@OthmanAdi commented on GitHub (Feb 20, 2026):

Thank you so much @gydx6 for this incredible contribution.

Your bug report was exceptionally detailed: you identified the exact scope (9 affected files), explained the root cause clearly, and then delivered a clean, well-tested fix. This is exactly the kind of thoughtful contribution that makes open source great.

The fix is now live in #79. I genuinely appreciate you taking the time to not only report this but to solve it properly. Welcome to the contributors of planning-with-files! 🙏

@OthmanAdi commented on GitHub (Feb 20, 2026): Thank you so much @gydx6 for this incredible contribution. Your bug report was exceptionally detailed: you identified the exact scope (9 affected files), explained the root cause clearly, and then delivered a clean, well-tested fix. This is exactly the kind of thoughtful contribution that makes open source great. The fix is now live in #79. I genuinely appreciate you taking the time to not only report this but to solve it properly. Welcome to the contributors of planning-with-files! 🙏

No labels

bug

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/planning-with-files#48

No description provided.

Rows
Columns