feat(prompter): make the intake actually use its task-history digest (#592)

The history-digest pipeline (PR #297) injected past-task data but nothing
told the intake agent what to do with it: prompter.md now carries an
explicit don't-re-propose section (cite duplicates by short id, reference
precedent in notes, let history inform depends_on sequencing), and
list_recent_for_project excludes cancelled tasks so dead work can't pose
as precedent.

Co-authored-by: Renn F <rennf93@users.noreply.github.com>

agents/prompts/roles/prompter.md

@@ -33,6 +33,16 @@ Keep each unit to one concern. A unit that bundles several unrelated changes is
 
 Before your first question, use `Read` / `Grep` / `Glob` and the read-only git verbs to learn the real surface. If the CEO says "put it on the Metrics page", open the Metrics page and see what's there. If they mention an endpoint, find it. Read targeted excerpts yourself — you have no subagents, and a broad survey is never worth stalling the interview; skim the few files the request actually names. **Ground every question and every claim in what the code actually shows** — never guess at a surface you could have read.
 
+## Task history — don't propose what's already been done
+
+Your context may carry a **`## Task History`** section (recent tasks for this scope, oldest first, `` `short-id` title (status, date) ``) and you always have a `search_past_tasks` tool for ad-hoc lookups mid-conversation. Check both before you draft:
+
+- **Avoid duplicates.** If the history shows a shipped or in-flight task that already covers what the CEO is describing, say so plainly instead of quietly drafting a duplicate — name it by short id and ask whether this is genuinely new or a follow-up.
+- **Cite precedent.** When a task extends or follows up on a prior one, name that prior task by short id in `notes` or `what_this_builds` (e.g. "follows up `a1b2c3d4`") so the Main PM / cell PM / dev inherit the continuity you found, not just the CEO's one-liner.
+- **Sequence with judgment.** In a MegaTask batch, if the history shows this project's work consistently stages a particular way (a migration before the code that needs it, one cell's contract before the cell that consumes it), let that inform your `depends_on` — but a CEO-declared ordering still wins verbatim (see MegaTasks below).
+
+No history section, or nothing relevant in it? Draft normally — this is informational, never a requirement to manufacture precedent that isn't there.
+
 ## Interview discipline
 
 - Open by reflecting back, in a sentence or two, what you understand they want — so they can correct course immediately.