des-log-phase splits execution-log across two directories

[tburny]

What happened?

des-log-phase --project-dir <relative-path> resolves the relative path against the caller's current working directory rather than the git/worktree root or the log's originally-initialized location. In a monorepo where an agent cds into a subdirectory (e.g. apps/website) partway through a DELIVER run, later des-log-phase calls silently create a second, divergent execution-log.json in that subdirectory instead of appending to the canonical log — with no warning that a new log was started instead of an existing one being found.

Steps to reproduce

1. des-init-log at a worktree root, initializing execution-log.json at (for example) docs/feature/<slug>/deliver/.
2. Log several phases with des-log-phase while the caller's cwd is still the worktree root.
3. cd into a subdirectory (e.g. apps/website) as part of normal step work.
4. Continue calling des-log-phase --project-dir . (or an otherwise-relative --project-dir) from the new cwd.
5. Run des-verify-integrity — it reads only the canonical directory and reports the later phases as missing, even though they were logged.

Expected behaviour

Either: (a) a relative/omitted --project-dir resolves against the worktree/git root (git rev-parse --show-toplevel, which in a linked worktree returns that worktree's own root, independent of cwd) rather than the caller's cwd; or (b) des-log-phase fails loud when pointed at a directory with no initialized log, instead of silently starting a fresh one; or (c) the log location is derived from the init-recorded location plus a feature-id, making --project-dir an override rather than the primary resolution path.

Actual behaviour

This ride, the entire 9-step execution log for a DELIVER run landed at the worktree root instead of the intended docs/feature/<slug>/deliver/ location, because a relative --project-dir was passed after the agent had cd'd into apps/website. The split was discovered only at des-verify-integrity time, which reported missing steps and forced a recovery/backfill pass. Reading the tool confirms the log format is a flat events append array with no integrity chain tying entries to a specific init — so a second log silently starts with no cross-reference to the first.

Environment

• Tool: des-log-phase / des-init-log / des-verify-integrity (DES execution-log CLI)
• Frequency: always, whenever --project-dir is relative and cwd has changed since init
• Regression? Not a regression — appears to be present since the CLI's initial --project-dir support

Logs / evidence

Confirmed by reading the des-log-phase implementation: a relative/omitted --project-dir is resolved via the process cwd at call time, with no worktree-root or init-location anchoring, and no existence check against a prior init before writing.

Related

• DES execution-log.json + git-commit non-atomicity breaks parallel multi-agent DELIVER waves #51 — non-atomic concurrent writers cause lost log entries; a different mechanism (race condition) producing a similar symptom (incomplete/split log at verify time)
• DES SubagentStop hook ignores nWave path override in AGENTS.md (forces dual-write) #53 (closed) — SubagentStop hook validated a hardcoded default path ignoring AGENTS.md override; that issue's own resolution states the DES CLI itself "already accepts --project-dir and works correctly with the override" — confirming this issue's specific defect (relative-path resolution against cwd) is not what DES SubagentStop hook ignores nWave path override in AGENTS.md (forces dual-write) #53 covered or fixed

---

surfaced during ride #49 (brand/visual system) on tobiasbrennecke-com, 2026-07-11

[tburny]

Cross-repo context: the symptom this root cause produces (stray root-level roadmap.json/execution-log.json from a prior feature's DES trace) is tracked as a consumer-side cleanup in tobiasbrennecke/dev-defaults-claude-plugins#120 and #121 (duplicates of each other, both open). Ownership confirmed on the consumer side: des-log-phase ships from the nwave-ai PyPI package (this repo), not from the consumer plugin repo, so the fix belongs here.

[11PJ11]

Thank you for the clear reproduction and the additional cross-repository context.

This has been fixed in nWave v3.22.0. Relative execution-log paths are now anchored to the current Git worktree, so changing into a subdirectory no longer causes later phases to be written to a second log. We also verified the original workflow from a nested directory.

If this now works as expected for you, would you please close the issue? If we do not hear otherwise, we will close it in three days. Please let us know if you still encounter a split or misplaced log.