feat: add phase 4 evidence semantics

[AVIDS2]

Summary

• add verification-aware evidence semantics as a computed display-layer concept
• show repository-backed evidence cues in detail and timeline outputs
• keep storage/schema unchanged and preserve backward compatibility

What changed

• add EvidenceBasis helpers in src/memory/disclosure-policy.ts
• extend compact detail formatting to show repository-backed evidence lines when signals are clear
• extend timeline anchor annotations to surface repository-backed evidence for git-backed entries
• add focused tests for evidence basis behavior and output formatting

Scope

This phase stays intentionally small:

• no schema/storage changes
• no graph rewrite or graph fusion
• no citation system
• no ranking changes

Validation

• npm run build
• npx vitest run tests/compact/evidence-basis.test.ts tests/compact/detail-provenance.test.ts tests/compact/timeline-provenance.test.ts

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ce46713478

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Scope observation lookup by project in detail formatting

compactDetail enriches each MemorixDocument by calling getObservation(doc.observationId), but getObservation matches only numeric ID and ignores projectId. For cross-project detail requests (the fallback path that fetches docs from Orama with projectId), a local observation with the same ID can be picked and its commitHash/relatedCommits copied into another project's detail, producing incorrect ✓ Repository-backed provenance and commit annotations. This is a correctness regression introduced by the new evidence-basis wiring.

Useful? React with 👍 / 👎.

[Copilot]

Pull request overview

This PR introduces “evidence basis” semantics as a computed, display-layer concept to surface when an observation is repository-backed (git-derived) versus direct/neutral, without changing storage/schema. It updates compact detail and timeline formatting to include repository-backed cues and adds focused tests for the derivation + formatting behavior.

Changes:

• Add EvidenceBasis + helpers (resolveEvidenceBasis, evidenceBasisLine) in src/memory/disclosure-policy.ts.
• Extend compact detail provenance headers and timeline anchor annotations to show repository-backed cues.
• Add vitest coverage for evidence basis derivation and output formatting.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File	Description
tests/compact/evidence-basis.test.ts	Adds unit tests covering derivation rules and formatting in detail/timeline outputs.
src/memory/disclosure-policy.ts	Introduces evidence-basis computation + a display helper line.
src/compact/index-format.ts	Displays repository-backed verification in detail provenance headers and timeline anchor annotations.
src/compact/engine.ts	Threads commitHash/relatedCommits from in-memory observations into detail formatting.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

In compactDetail, this reintroduces an ID-only getObservation(doc.observationId) lookup for every formatted document. When documents includes Orama fallback results from another project, getObservation returns the current project's observation with the same numeric ID (observations are stored per-project in-memory), which can attach the wrong commitHash/relatedCommits and display incorrect “Repository-backed” evidence (and potentially leak unrelated commit hashes). Consider only using the in-memory observation when obs?.projectId === doc.projectId (or threading the already project-validated obs alongside the doc when building documentMap).

Suggested change

	let detail = formatObservationDetail({
	...doc,
	commitHash: obs?.commitHash,
	relatedCommits: obs?.relatedCommits,
	const safeObs = obs && obs.projectId === doc.projectId ? obs : undefined;
	let detail = formatObservationDetail({
	...doc,
	commitHash: safeObs?.commitHash,
	relatedCommits: safeObs?.relatedCommits,

[Copilot]

The comment says repository-backed is “grounded in an actual git commit”, but the condition also treats source === 'git' and sourceDetail === 'git-ingest' as repository-backed even when commitHash is missing. Either tighten the logic to require commit evidence (commitHash/relatedCommits) or update the comment to match the broader “git provenance implies repository-backed” rule.

[Copilot]

evidenceBasisLine is documented as being used for “timeline anchor annotations”, but formatTimeline builds its own hard-coded suffix string instead. To avoid drift in phrasing/casing, either reuse evidenceBasisLine for the timeline path (possibly with an option for the lower-case variant) or adjust the docstring so it only claims the usages that actually exist.

Suggested change

	* Return a compact one-line verification annotation for provenance headers
	* and timeline anchor annotations.
	* Return a compact one-line verification annotation for provenance headers.

[Copilot]

Timeline anchor annotations hard-code — ✓ repository-backed instead of reusing evidenceBasisLine, which produces ✓ Repository-backed (different casing/wording). This duplication makes it easy for the two outputs to drift. Consider centralizing the formatting (e.g., a dedicated helper for the timeline suffix) so both detail and timeline stay consistent.

Suggested change

	const basisSuffix = anchorBasis === 'repository' ? ' — ✓ repository-backed' : '';
	const basisLine = evidenceBasisLine(anchorBasis);
	const basisSuffix = basisLine ? ` — ${basisLine}` : '';