Blueprint store is 78% cross-project contamination

Per project

Bar shows the foreign share. A dot marks projects with zero correctly-placed blueprints.

Two unregistered project directories also exist (E351091F…, E81793D1…) holding one file each — orphans from deleted projects.

What the evidence looks like

This isn't inferred from filenames. The blueprints name the wrong app in their own opening lines:

Peregrine/cloud-sync.json
  "Cloud Sync is Hopper's optional, fail-safe backup and cross-device layer…"

Peregrine/ios-app-ui.json
  "…the SwiftUI presentation layer for Keep Sparrow, a local-first
   book-capture app…"

Peregrine/app-shell.json
  "This is the App Shell & Navigation subsystem of Hopper — a Svelte 5
   client-only PWA (NOT the Swift/macOS SnapSparrow app described in the
   stale prior blueprint…)"

That last one is doing something grimly funny: it's a regenerated blueprint correcting a previous mis-association, filed under a third project entirely.

CodeRaven's own directory is the worst offender by volume

34 of its 48 blueprints belong elsewhere — SnapSparrow's design-system, Atticus's room-concept and domain-models, Keep Sparrow's ios-app-ui, NoteSparrow's note-editing, Hopper's cloud-sync. Peregrine's old index.md listed exactly this set, which is how the SnapSparrow and room-* names reached Peregrine in the first place.

Root cause — partly known, partly not

It does not explain full blueprint content for Keep Sparrow, Hopper and Atticus sitting in other projects' directories. I checked every saveBlueprint call site — all twelve pass an explicit projectId, so there's no obvious active mis-write. Two hypotheses worth testing, neither confirmed:

• Historical, not ongoing — generation ran against the wrong project root before the fallback was fixed, and the artefacts were never cleaned up. Consistent with file dates clustering in mid-July.
• Stale singleton scope — BlueprintStore is a shared instance with a loadedProjectId; a generation kicked off before a project switch completes could resolve the wrong ID upstream of the call site.

Distinguishing these matters: if it's historical, deleting is a permanent fix. If it's live, the contamination returns.

Recommended sequence

1. Quit CodeRaven (currently running as a Debug build, pid 28166). Its in-memory store will rewrite files on next save otherwise.
2. Back up the whole Blueprints/ directory to a timestamped copy — 248 deletions deserves an undo.
3. Delete the 248 foreign records (and the 2 orphan directories). The 63 correct ones stay.
4. Regenerate on demand with /cr-blueprint <subsystem> per project, rather than bulk-regenerating 248 blueprints nobody has asked for yet.
5. Verify it doesn't recur — generate one blueprint, switch projects, generate another, and re-run this audit script.

Method & caveats

Script: audit_blueprints.py (in this session's scratchpad). For each stored blueprint it scans overview, keyFiles, entryPoints and gotchas for the names of all 17 registered projects.

The rule is deliberately conservative: a blueprint is flagged only when its owning project's name is entirely absent and another project's name is present. Anything mentioning its own owner passes, even if it also names another project — so Peregrine's prototyping-docs, which legitimately references CodeRaven's review template, would not be flagged.

• False negatives are likely. A misfiled blueprint that never names any project reads as "unknown" (6 cases) and isn't counted as foreign. The real number is ≥248.
• False positives are unlikely but possible — a blueprint genuinely about integrating with another app would trip the rule. Worth a glance at the detail list before deleting.
• scan-history.json and custom-subsystems.json are sidecars, excluded from all counts.