Phase 153: Hash labeling & disambiguation across all interfaces#128
Conversation
Schedule Phase 153 to eliminate ambiguity between blob hashes (internal, content-addressed) and commit hashes (Git-level, user-visible) across all interfaces (CLI, MCP, HTTP, HTML). Design doc: docs/hash-labeling-plan.md - Root cause: renderResults() outputs unlabeled [hash] hashes - Solution: Add blob: prefix to distinguish hash types - Impact: Cascades across search, first-seen, code-search commands - Risk: Low — single-line change, no API/schema changes Acceptance criteria: - All text output includes [blob:...] prefix for blob hashes - HTML renderers show "Blob Hash" column - OpenAPI docs clarify blobHash vs firstCommit fields - MCP interpretations guide LLMs - Tests verify hash labeling - JSON structures unchanged (backward compatible) Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W4f2bLeAz3MxUoUGopFxkm
|
@copilot Please see the plan for phase 153 in this PR (see diff) and complete the phase 153. |
Phase 153 is now complete. Here's what was implemented: Core change ( HTML renderers ( OpenAPI ( MCP interpretations ( Tests ( No JSON field names, API shapes, or database schema were changed — fully backward compatible. |
|
@copilot Please resolve conflicts and update PR desc. |
Resolved the merge conflict by bringing this branch up to date with |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Summary
This PR schedules Phase 153 to fix hash ambiguity across gitsema's user-facing outputs (CLI, MCP, HTTP, HTML).
Problem: Users see unlabeled hashes like
[abc1234]in search results and naturally interpret them as commit hashes (the Git-level identifier they know). In reality, these are blob hashes (content-addressed, internal implementation detail). This causes confusion, especially when LLMs/Claude read the output.Example:
Users think
[abc1234]is a commit hash. It's actually a blob hash.Solution
Root cause:
src/core/search/ranking.ts:53definesrenderResults(), which outputs unlabeled hashes. This function ripples across:gitsema search,first-seen,code-searchsemantic_search,code_search,search_history/search,/first-seen(text rendering mode)Fix: Add
blob:prefix to distinguish hash types. Single-line change that cascades across all interfaces.Impact
What changes (user-facing)
[abc1234]→[blob:abc1234]blob:prefixblobHashvsfirstCommitfieldsWhat doesn't change (backward compatible)
blobHash,firstCommitunchangedRisk Assessment
Low risk:
Files in this PR
docs/hash-labeling-plan.md(new)docs/PLAN.md(modified)Next Steps (When Ready to Implement)
Use
/execute-plan Phase 153to:src/core/search/ranking.ts:60(1-line change)tests/ranking.test.tsRelated Issues
Closes #hash-surfacing (internal audit finding)
📋 Checklist for implementation phase:
renderResults()function🤖 Generated with Claude Code
Generated by Claude Code