Bug: potential-to-issue-promoted-copy-not-written

[drmoisan]

• Work Mode: full-bug

Summary

mcp__drm-copilot__potential_to_issue returns a success receipt naming a
destination_path under docs/features/potential/promoted/, but no file is written
to that path. The source potential entry is removed from
docs/features/potential/, so the on-disk potential document is destroyed while the
receipt asserts it was relocated.

Environment

(not provided in potential file)

Steps to Reproduce

(not provided in potential file)

Expected Behavior

Either:

1. The file is actually written to the reported destination_path, matching the
   receipt; or
2. The receipt does not report a destination_path that was not written.

A success receipt must not assert a filesystem outcome that did not occur.

Actual Behavior

(not provided in potential file)

Logs / Screenshots

(not provided in potential file)

Impact / Severity

(not provided in potential file)

Source

From: docs/features/potential/2026-08-14-potential-to-issue-promoted-copy-not-written.md

[drmoisan]

Scope narrowed: does not reproduce on the bug/full-bug path

Immediately after filing this issue, two further promotions were run in the same worktree and the same session:

• 2026-08-14-potential-to-issue-promoted-copy-not-written.md -> issue Bug: potential-to-issue-promoted-copy-not-written #554, promotion_type: bug, work_mode: full-bug
• 2026-08-14-orchestrator-hooks-reference-absent-python-validators.md -> issue Bug: orchestrator-hooks-reference-absent-python-validators #555, promotion_type: bug, work_mode: full-bug

Both wrote the promoted copy correctly. Verified on disk:

docs/features/potential/promoted/2026-08-14-orchestrator-hooks-reference-absent-python-validators.md
docs/features/potential/promoted/2026-08-14-potential-to-issue-promoted-copy-not-written.md

The originally observed failure was on promotion_type: feature, work_mode: full-feature. The bug therefore does not reproduce unconditionally, and the reproduction steps in the issue body are too broad as written.

Corrected reproduction hypothesis: the missing-copy behavior is specific to the feature promotion path (or to full-feature work mode), not to potential_to_issue generally. The bug path is confirmed working.

The first acceptance criterion should be read as scoped to whichever path actually fails; investigation should start by diffing the feature and bug branches of the promotion implementation.

Severity is unchanged: a silent content loss on the feature path is still the most common promotion path in this repository.

[drmoisan]

Correction: the deleting tool is new_active_feature_folder, not potential_to_issue

This issue's diagnosis is wrong and should be re-scoped before anyone investigates.

What actually happens. potential_to_issue does write the promoted copy to docs/features/potential/promoted/. It is new_active_feature_folder, called afterwards, that consumes and deletes it — its content becomes the active folder's issue.md. This is pre-existing known behavior, recorded independently on issue #398 (2026-07-21).

Why the original observation misled. The call order for #553 was:

1. new_potential_entry
2. potential_to_issue -> issue Feature: ci-parallel-job-split #553, reported destination_path under promoted/
3. new_active_feature_folder -> created the active folder
4. checked the filesystem — file absent from both locations

The check happened after step 3, so the deletion was attributed to step 2.

This also explains the earlier scope-narrowing comment. The two bug promotions (#554, #555) left their promoted/ copies intact not because the bug path differs from the feature path, but because new_active_feature_folder was never called for them. The feature-vs-bug hypothesis in that comment is unsupported; disregard it.

What remains worth fixing, at reduced severity:

potential_to_issue's receipt reports a destination_path that a subsequent standard-workflow call predictably removes. That receipt is persisted verbatim into orchestrator-state.json under delegation_receipts.promotion.issue, so checkpoints routinely record a path that does not exist by the time anyone reads them. The content is not lost — it survives in the GitHub issue body and in the active folder's issue.md — so this is an audit-trail accuracy defect, not the content-loss defect originally described.

Suggested re-scope: either have new_active_feature_folder leave the promoted/ copy in place, or have the promotion receipt state that the destination is transient. The acceptance criteria in the issue body should be rewritten accordingly; as written they target the wrong tool.