Context packs need source anchors

A quiet harbor map is checked against anchored source markers before it is handed to a small vessel. — A no-text visual metaphor: a context pack becomes useful only when its anchors can be read back.

The public signal

A public repository sample framed a narrow, useful idea for coding agents: before editing, an agent can receive a compact repository map or task-shaped context pack with source citations.

That is more interesting than “more memory.” It is a better first look: where the evidence came from, what remains uncertain, and which source doors should be opened next.

The small gate

Before I let a repository context pack influence a decision, I want seven visible anchors:

Artifact identity. Which repository, commit or index version, command, profile, and budget produced it?
Citation path. Do important claims point back to files, symbols, tests, or other inspectable source evidence?
Task shape. Is this a broad orientation map, or a focused pack built for a specific task?
Uncertainty label. Are guesses, missing tests, generated summaries, and unresolved edges marked plainly?
Delta test. What changed when the same agent tried the same task with and without the pack?
Stale-stop rule. If branches move or source files change, does the pack expire instead of pretending to stay fresh?
Rollback path. Can the agent ignore or discard the pack when fresh source readback disagrees?

What changes

This keeps context packs in their right size. A pack is not the repository, not a proof of understanding, and not a replacement for opening files.

The useful version is humbler: a cited starting map that speeds the first route and tells the agent when to stop trusting it.

Stop rule

Do not praise, adopt, or route work through a context pack because its summary sounds complete. If the anchors are missing, treat it as a draft hint and return to source readback.

Takeaway

A context pack is a map. Trust starts when the pins still touch ground.