Can Kin tell two same-name functions apart, and keep an edit through a restart?

The question

Can saved Kin replies distinguish two same-name Go functions, and can a separate local capture read a native edit through a fresh client after a daemon restart?

Expected interpretation. The caller examples resolve two specific identities and their recorded sites. The separate history capture preserves the focal identity across one native edit and reopen. Each setup is named separately; neither proves complete references, faster work or v0.8.0 acceptance.

Build, source and preparation

Kin build

v0.7.20, aarch64-apple-darwin, commit 9af9b04437fe380b2376e4ceb1fdaa69679b02dc. Release on GitHub

Source repository

cli/cli, prepared one-commit snapshot, head c033f2961104e1f932406325341147ace3b7ff21, 1 reachable commit, 921 files

Released archive measured

kin-macos-aarch64.tar.gz, sha256 c8f459855935fd7edc6be4b3b5dffe2be66905faf6deb712908c0971971904a8

Environment and preparation

The earlier caller replies use gopls. The separate history capture uses the full MCP profile, CPU, no automatic embedding and no gopls. Local paths are omitted from the public preparation metadata. source

Graph-readiness output

The saved references report partial coverage and an inconclusive verdict. Recording warned that cross-file enrichment was still catching up. The observed caller rows do not mean enrichment completed. source

Capture date

2026-09-17 (gopls caller replies); 2026-09-22 (separate history capture). Two separately recorded configurations on a dated released build, preserved with their limits. It is indexed on the proof archive.

How each result was checked

1. The two saved answers identify two different functions that share the name listRun, behind gh issue list and gh secret list.

   Read the focal UUID, file and reference rows from each independently saved gopls-assisted reply. Both replies report 20 same-name candidates; this package displays two captured identities, not an exhaustive candidate-list capture.

   Issue-list replySecret-list reply

2. An edit recorded in Kin was still there when a new session read it back after Kin was stopped.

   The imported state and the native state have different semantic change IDs. Each displayed body matches the recorded full-body hash for that state. The capture observed the old daemon absent, then queried a fresh client and new daemon for the native change. UUID continuity is asserted only within this separate capture.

   db6e4fb4cedc3590f8d8c1e02ec2464eb8676ef416be86030300c30cdccda257

   Reopened focal extractRecorded full-body diff

Timing methodology. No timing or comparative performance claim is made. The capture records lifecycle timestamps only.

Recorded limitations

Partial references and an overbroad history response. The Go build does not produce entity-level import edges. The history setup had no language server, and cross-file enrichment remained incomplete. Released entity_history returned entire change records; the browser downloads are labelled compact focal extracts with exact full-reply hashes retained in the offline audit.

Record warningExtraction scope and full-reply hashes

What this case does not establish, as its receipt records it:

• Saved local demonstration using released Kin 0.7.20; not v0.8.0 candidate acceptance.
• The cache-lifetime edit is a task-owned demonstration change, not a change from upstream GitHub CLI.
• The record command warned that cross-file enrichment was still catching up. Its full output is supplied as go-history-record.txt. The preserved three caller rows do not imply that background cross-file enrichment completed.
• References are a lower bound: Kin reports an inconclusive verdict and partial coverage because this build produces no Go entity-level import edges and this setup has no Go language server. The three observed rows do not establish exhaustive absence.
• The full MCP profile was explicitly selected because agent-default does not expose entity_history. Only list_file_entities, find_references and entity_history were invoked through MCP.
• Entity UUID continuity is asserted only within this capture, across the edit and daemon reopen. The two caller answers come from separate runs with their own setup.
• The first state is a Kin semantic change imported from the prepared Git snapshot, not a native-origin edit. The second change has native origin.
• Compact history extracts retain only focal-entity deltas plus change metadata. Full original replies remain in the local audit bundle and are identified by SHA256 and byte count; released entity_history returned entire change records, including 6082 imported entity deltas.

Not recorded

A field with no receipt behind it is listed here with the state recorded for it, rather than filled in with a plausible guess. The rows that link a source are named from that receipt's own keys and carry its exact wording, so a reader can find each one in it. Nothing below is a result.

Independent reproduction

not recorded. No outside party independently reproduced these captures.

Comparative performance

not recorded. No time, task-token, cost or correctness advantage was measured by these demonstrations.

Every file below is committed with its own sha256 sidecar, listed in manifest.json, and checked against that manifest at every build by check-proof-artifacts.mjs. This table is generated from that manifest, not typed by hand. check-case-record-integrity.mjs then reads this rendered page back and fails the build on a row the manifest does not list, a manifest row this table dropped, a row rendered twice, a row carrying another row's label, a byte count or hash here that stopped matching the manifest, and any row that did not come from the manifest at all.