brv curate on CLI 3.16.1 appears to ignore supplied text and generate unrelated internal RLM/meta review content

[Kenmege]

ByteRover public-safe support ticket

1. Title

brv curate on CLI 3.16.1 appears to ignore supplied text and generate unrelated internal RLM/meta review content

2. Summary

I have a reproducible/local evidence set where brv curate "<targeted text>" on ByteRover CLI 3.16.1 did not use the supplied curation text for several targeted entries. Instead, pending review operations were generated around unrelated internal RLM workflow/meta content. One contrast entry succeeded, which suggests the issue is not a total curate failure but a content-isolation/substitution bug.

3. Environment

• ByteRover CLI: byterover-cli/3.16.1 on macOS ARM64.
• Provider class: external OpenAI-class provider configured through ByteRover; no API key or raw external-provider output included here.
• Project shape: local project root with .brv/context-tree, git-semantic context tree, and multiple linked worktrees.
• Reproduction context: direct CLI curation from the parent project root; no folder/bulk ingestion flags and no bulk private-source ingestion.

4. Reproduction overview

Targeted curation entries were submitted as direct single-argument CLI calls in this shape:

brv curate "<sanitized targeted curation text>"

Observed result matrix:

Case	Sanitized target	Result
C1-v2	Current mandate anchor	Failed: reported or queued content did not reflect supplied text; controlled retry misrouted to RLM/meta content.
C2	Worktree link semantics	Succeeded: correct content landed and query round-trip passed.
C3	Source hierarchy	Failed: unrelated RLM/meta content generated.
C4	Decay / last-verified rules	Failed: unrelated RLM/meta content generated; one interrupted/orphan variant was observed.
C5	Agent coordination	Failed: unrelated RLM/meta content generated.
C6-v2	Fixture register	Failed: unrelated RLM/meta content generated.

Summary: five targeted entries failed in the first pass, then a controlled retry reproduced the C1-v2 failure. C2 succeeded and is useful as a contrast case.

5. Expected behavior

• brv curate "<text>" should use the supplied text as the source content for extraction and review operations.
• Review operations and target paths should reflect the supplied concept, not unrelated internal workflow/meta content.
• A success message should only be emitted when a matching file/review operation is actually produced.
• Approve/reject workflows should keep body files and sidecar files consistent.

6. Actual behavior

• Supplied text was ignored/substituted for several targeted curation attempts.
• Review operations were generated for unrelated RLM/meta workflow files.
• One run reported successful curation even though no matching target body file was found in the expected context-tree area.
• Later review/body observations showed body/sidecar inconsistencies around affected RLM files.

7. Why this blocks use

This blocks safe use of brv curate for source-of-truth project memory. If the curation engine can substitute unrelated internal context for supplied text, then review tasks may look plausible while encoding the wrong knowledge. We are containing ByteRover as non-authoritative for the affected mandate until the defect is understood and regression-verified.

8. Side effects observed

• Junk review tasks were generated from unrelated RLM/meta content.
• Pending review counts were confusing across brv status and brv review pending --format json.
• Body/sidecar inconsistency was observed: missing approved body file, orphan sidecars, and rejected/variant bodies persisting or being restored.

9. Evidence available on request

A sanitized evidence bundle can be provided with:

• CLI/version/status snapshots.
• Redacted reproduction logs.
• Redacted review pending snapshots.
• Sanitized body/sidecar state observations.
• Contrast proof for the C2 worktree semantics success.

No secrets, API keys, raw external-provider output, private paths, or sensitive doctrine are included in this public ticket.

10. Requested guidance/fix

Please advise or fix:

1. Is this a known brv curate content-substitution / internal prompt leakage issue in CLI 3.16.1?
2. What is the safest minimal repro format you prefer?
3. Can brv curate success reporting be made conditional on actual review/file operations reflecting the supplied input?
4. Can the curate/review pipeline isolate user-supplied input from internal RLM workflow context?
5. How should users recover orphan sidecars, missing body files, persisted rejected bodies, or reject-restored variants?
6. What are the intended semantics of pendingReviewCount versus pendingCount?
7. Should affected users avoid brv curate until a CLI fix or workaround is available?

11. Safety/containment currently in place

• No further brv curate use for affected source-of-truth entries.
• No review approve/reject action on current questionable review tasks.
• No direct .brv/context-tree edits until ByteRover confirms whether that is safe/indexed.
• Affected memory is treated as non-authoritative until fixed and regression-verified.