Bug
When running project-expert scan --state closed, the scan fetches issues and creates an entry with a "Topics to Explore" section, but new topics are not added to the queue if their target already exists in .project-expert/topics.json — even if the existing entry has status done.
Steps to Reproduce
- Run
project-expert scan on a project (creates topics, explores them, marks them "done")
- Run
project-expert scan --state closed (discovers some of the same targets in a new context)
- New topics with previously-explored targets are silently dropped
Root Cause
In ftl_project_expert/topics.py, add_topics() line 54:
existing_targets = {t.target for t in queue} # no status filter
This creates a set of ALL targets regardless of status. Topics with targets that already exist as "done" or "skipped" are skipped by the dedup check on line 57, even though they represent genuinely new discoveries from a different scan context.
Expected Behavior
Topics from a new scan should be enqueued as "pending" even if the same target was previously explored. A re-scan with different filters (e.g., --state closed vs open) surfaces different information and the follow-up questions are different.
Suggested Fix
Filter deduplication to only skip targets that are already pending:
existing_targets = {t.target for t in queue if t.status == "pending"}
Or, if re-exploring "done" topics should require explicit opt-in, add a --force flag to the scan command.
Bug
When running
project-expert scan --state closed, the scan fetches issues and creates an entry with a "Topics to Explore" section, but new topics are not added to the queue if their target already exists in.project-expert/topics.json— even if the existing entry has statusdone.Steps to Reproduce
project-expert scanon a project (creates topics, explores them, marks them "done")project-expert scan --state closed(discovers some of the same targets in a new context)Root Cause
In
ftl_project_expert/topics.py,add_topics()line 54:This creates a set of ALL targets regardless of status. Topics with targets that already exist as "done" or "skipped" are skipped by the dedup check on line 57, even though they represent genuinely new discoveries from a different scan context.
Expected Behavior
Topics from a new scan should be enqueued as "pending" even if the same target was previously explored. A re-scan with different filters (e.g.,
--state closedvs open) surfaces different information and the follow-up questions are different.Suggested Fix
Filter deduplication to only skip targets that are already pending:
Or, if re-exploring "done" topics should require explicit opt-in, add a
--forceflag to the scan command.