Are we indexing and embedding the commits in a given project? (maybe n

## Question (resolved) "Are we indexing + embedding commits per project? Should we? What about removed/merged branches?" ## Answer (verified against code 2026-07-03) **Yes — flower already indexes AND embeds commits:** message + changed-file-path list (no diffs). `Commit` model → `commits` table (unique project_id+sha), ingested by `flower:ingest-commits` / `CommitIngestService`, embedded as `commit`-tagged Chunks by `EmbedChunks::buildCommitChunks()`, surfaced in recall_search + recall_touching / recall_file_story / recall_resume / recall_brief; brief trailers auto-link commits↔briefs. **The real gap (branch handling):** commits have no branch attribution and are deduped by sha; nothing flags/prunes them when a branch is deleted / merged / rebased, so abandoned-experiment and force-push-orphaned commits persist indistinguishably from merged-to-master work. Recommendation: do NOT prune (memory tool) — add soft enrichment instead. ## Decision (operator, 2026-07-03) **Build the enrichment as a follow-up brief — GATED on an early feasibility/cost spike first** (measure reconciliation cost across a range of repos incl. large ones; don't build it out if too expensive to run). ## Follow-up Spun out to **#101 — "Commit branch attribution + soft reachability enrichment (spike-gated)"** (Phase 0 cost spike → Phase 1 build on operator go). This brief (#69) is **closed as answered** — the question is resolved and the actionable work now lives in #101. ## Provenance Operator note (#69, 2026-07-02). Answered by flower-orchestrator (evidence) + flower-refine (2026-07-03); operator decided build-with-spike-gate (2026-07-03); work spun out to #101 by flower-refine.

Build the enrichment (branch attribution + soft reachability flag) as a follow-up brief - let's ensure that we do some sort of early testing before building the whole thing out to see what kind of cost there is actually performing the reconciliation on a range of targets so we know if this is something that won't be feasible to run on some of these large repos or if it's trivial or what. I don't want to build it out if we're not going to be able to or want to use it because it's so expensive, computationally or otherwise.

Confirmed against the code: flower already indexes AND embeds commits (message + changed-file list, no diffs) and surfaces them in recall_search / recall_touching / recall_file_story. The real gap the orchestrator surfaced: commits have no branch attribution and nothing prunes/flags them when a branch is deleted, merged, or rebased — so an abandoned-experiment commit and a force-push-orphaned sha persist indistinguishably from merged-to-master work. Recommendation is NOT to prune (flower is a memory tool — losing that history is the anti-goal), but to add soft enrichment: (a) record the branch/ref a commit was first seen on at ingest, and (b) a periodic reconciliation that soft-flags commits no longer reachable from any live ref as `superseded`/`unreachable` (a status flag, NOT a delete) so recall can badge / de-emphasize / optionally filter them ('live history only'). Do you want this enrichment built as a follow-up brief, or should #69 close as 'answered — working as intended, enrichment optional'?

Answer (evidence-backed, verified against the code 2026-07-03): **Yes — we already index AND embed commits.** Not the code/diffs, exactly as you guessed: commit **message + changed-file-path list** (no diffs, no code content). - Model/table: `Commit` (`app/Models/Commit.php`) → `commits` table, unique on `(project_id, sha)`, columns sha/message/files(json)/author/authored_at/meta. `morphMany(Chunk)`. - Ingest: `flower:ingest-commits` → `CommitIngestService` runs `git log …%B --name-only` per indexed path/worktree, upserts by `(project_id, sha)` (skips existing unless `--force`). - Embedded as searchable chunks: `EmbedChunks::buildCommitChunks()` makes one Chunk per in-scope commit, tag `commit`, text = message + "Changed files:" list, re-embeds on change. Surfaced in `recall_search` (Meili, `commit` source) AND via direct SQL in `recall_touching` / `recall_file_story` / `recall_resume` ("did my next steps already land?") / `recall_brief`. Brief trailers (`Brief: #id`) auto-link commits↔briefs. **So we're doing it. The real question you intuited is branch handling — and here's the gap:** - Commits have **no branch column** and are **deduped by sha per project** (a commit reachable from many branches is stored once). Ingest reads whatever HEAD resolves to in each indexed path (no `--all`). - **Nothing prunes commits when a branch is deleted/merged/force-pushed.** There is zero git-reachability reconciliation. `OrphanedChunkPruner` only deletes chunks whose *DB row* is gone — the Commit row is never deleted on branch removal, so its chunk lives on. Result: a commit from a since-deleted or rebased-away branch persists permanently in DB + Meili — orphaned-from-git but still fully searchable. The only branch/merge logic that exists (`GitInspector::mergeStatus()`) feeds **brief-completion suggestions**, not commit storage. **My thoughts / recommendation:** 1. **Don't prune on unreachability.** flower is a *memory* tool — a commit that was real work (even on a deleted experiment branch) is legitimate durable history you may want to recall ("what did I try on that spike?"). Garbage-collecting by git-reachability would erase memory, which is exactly what we're building against. So keep storing. 2. **But add soft branch/reachability enrichment** (a real, bounded follow-up if you want it): - record the branch(es)/ref a commit was first seen on (cheap: `git log` already knows the source path/worktree branch at ingest), and - a periodic reconciliation that soft-flags commits no longer reachable from any live ref as `superseded`/`unreachable` (a status flag, NOT a delete), so recall can badge/de-emphasize them and optionally filter (e.g. "live history only"). This fixes the two actual quality issues — (a) can't distinguish merged-to-master from abandoned-experiment commits; (b) force-push/rebase leaves the old sha as a near-duplicate of the new one — **without** losing any memory. Net: we're already doing the valuable part (message+files embedded). The worthwhile next step is *attribution + soft reachability status*, not pruning. If you want that built, say so and I'll spec it as a follow-up brief; otherwise this brief can close as "answered — working as intended, enrichment optional."