Skip to content

feat(file-refs): distinguish unverified file refs from verified-current - #67

Merged
7vignesh merged 1 commit into
7vignesh:mainfrom
ZeroTang05:fix/unverified-file-refs
Oct 19, 2026
Merged

7vignesh merged 1 commit into
7vignesh:mainfrom
ZeroTang05:fix/unverified-file-refs

Conversation

@ZeroTang05

Copy link
Copy Markdown
Contributor

What this changes

A memory that named an untracked, gitignored or made-up path used to render with no marker at all — exactly like a memory whose file was checked and is current. A reader could take the absence of a warning as confirmation, when in fact nothing was ever checked.

This records what was named, not only what resolved, and renders the two cases with different advisories.

  • memory_file_refs gains a tracked column (append-only migration 012_add_file_refs_tracked; existing rows are tracked by definition, since every one of them came from a path that resolved).
  • recordFileRefs stores every path the note names. A path git cannot resolve is stored with tracked = 0.
  • findUnverifiedFileRefs returns those paths per memory.
  • Read time renders them as ⓘ unverified: <path> (untracked), separate from the existing ⚠ may be stale drift marker.

The three states now read differently:

state marker
tracked + drifted ⚠ may be stale: <path> changed since this was written
tracked + unchanged none
named but never resolved ⓘ unverified: <path> (untracked)

Unchanged

  • The drift marker and its semantics for tracked files.
  • The output format.
  • Non-git workspaces: no refs are recorded there, so no advisories are emitted.
  • A memory that names no path stays completely markerless — an "unverified" on every convention or decision memory would be noise on the majority of memories.
  • Ranking: this is write-path plus rendering only. npm run bench:check reports no drift, and no new snapshot is committed.

Tests

  • recordFileRefs stores every named path and marks which ones git could resolve.
  • findUnverifiedFileRefs reports named-but-unresolved paths, and is empty for a fully tracked memory.
  • formatContext renders the unverified marker in text and markdown, keeps it distinct from the stale marker, and emits neither for a memory that names no path.

npm run ci is green (typecheck + typecheck:bench + tests + build + smoke); 272 tests pass.

Refs #66

A memory that named an untracked, gitignored or made-up path rendered with
no marker at all, which reads exactly like a memory whose file was checked
and is current. An agent could take the absence of a warning as
confirmation that the memory was still accurate, when in fact nothing was
ever checked — worst for the paths most likely to move: new, generated or
gitignored files.

Keep the throttle and the delivery filter apart, and record what was
named rather than only what resolved:

- `memory_file_refs.tracked` (append-only migration 012) marks whether a
  path resolved at HEAD when the memory was written.
- `recordFileRefs` now stores every path a note names; unresolved ones
  are stored with `tracked = 0`.
- `findUnverifiedFileRefs` reports those paths per memory.
- Read time renders them as a distinct advisory,
  `ⓘ unverified: <path> (untracked)`, separate from the existing
  `⚠ may be stale` drift marker.

Unchanged: the drift marker and its semantics for tracked files, the
output format, and the non-git workspace (no refs are recorded there, so
no advisories are emitted).

A memory that names no path stays markerless — "unverified" on every
convention or decision memory would be noise.

Refs #66
@vercel

vercel Bot commented Oct 19, 2026

Copy link
Copy Markdown

@Warma10032 is attempting to deploy a commit to the vignesh's projects Team on Vercel.

A member of the Team first needs to authorize it.

@7vignesh
7vignesh self-requested a review October 19, 2026 21:44
@7vignesh
7vignesh merged commit 8b8a3be into 7vignesh:main Oct 19, 2026
4 of 5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants