[gedaiu]

Part of #1293. Thank you for the careful ADR and for the steer on the plan test. This is decisions 1 to 4 of 0071. A statements source with {"names": "identity"} in its config now attaches each name to the single live entity holding the exact name (ignoring case, in the declared class or none) whatever the profile says, creates it when there is none, and keeps today's path when two entities hold it. A name that only exists under another class is created in the declared class and keeps the type-drift review unless the classes are declared disjoint. Such a source also skips the embedding client, so it asks for no name vectors and runs no nearest query. Decisions 5 and 6 are left for the next PR, so vectors already stored and the pending backfill are untouched, and identity names can still get vectors from the backfill that runs after a prose document until then.

The server test an_identity_source_adds_no_name_vectors_and_asks_no_neighbours counts calls on a fake embeddings endpoint and expects none and no name_vector| rows, with a sibling test showing the same push without the flag does embed and queue a pair. Two store tests cover the attach, create, two-holder and other-class cases, and the flag has unit tests. They fail when the embedding gate or the attach branch is removed. I ran the utopia-store, utopia-core and utopia-server tests against a fresh database, plus fmt and clippy with -D warnings, all green, including the plan test and the_same_literal_name_is_not_proposed_twice.

🤖 Generated with Claude Code

[WaylandYang]

Decisions 1–3 read as the record says, and the embed-count test is the right test for decision 4. One gap blocks it.

resolve_identity_name matches only lower(e.canonical_name). Every other channel-1 lookup on dev (resolve_by_name, resolve_type_drift, existing_by_name) also checks name facts through names::has_name_in, because 0041 made name facts the recall bridge and a merge moves the loser's names onto the survivor as known_as facts (the merge path in resolution.rs). Scenario: identity entity owner/repo:src/a.ts is merged into a prose entity, by a person or the adjudicator; the next push of the same external_id finds no holder and recreates the entity that was just merged away. The fallback half of the same function does use has_name_in, so the two halves of one function recall differently. Please add the name-fact clause to the holder query, with one test: a holder known only by a known_as fact attaches.

Smaller:

• The status line says open: decisions 5 and 6, but decision 4's name_vectors::pending skip is also left to the next PR (as you note in the description); the record should say so, or the next PR's scope will be misread.
• Attaching a typed identity mention to a holder with type_id IS NULL never upgrades the holder's class, while the drift path does. Decision 3 makes the class part of the identity claim; fine to leave for PR2 if you say so in the record.
• The new comments in resolution.rs and models.rs are English inside Chinese files.

[gedaiu]

Thank you for the careful review, and for the scenario, which I had missed. The holder query now also matches name facts through names::has_name_in, so an identity entity that was merged into another still attaches on the next push. A new case in the store test covers a holder known only by a known_as fact, and it fails without the clause. The 0071 status line now lists the pending skip with decisions 5 and 6, a short paragraph says a typed mention does not upgrade an untyped holder's class yet, and the new comments are in Chinese. The branch is also rebased on dev. Ready for another look whenever you have a moment.

[gedaiu]

A gentle ping whenever you have a moment, no rush. The blocking point is fixed: the holder lookup now reads name facts through names::has_name_in, with a test for a holder known only by a known_as fact. The status line, the class-upgrade note and the Chinese comments are done too. Thank you for the careful review!

[WaylandYang]

The blocking point is fixed: the holder query now reads name facts through has_name_in, and the test holder is known only by a known_as name, so only that clause can satisfy it. Two small things before it lands:

• In 0071 the new paragraph "A NULL-typed holder keeps its class for now" sits directly after the - **Off:** bullet with no blank line, so Markdown renders it as a continuation of that list item under decision 6. Add the blank line.
• The comment on resolve_type_drift's new may_attach parameter is English in a Chinese file.

#1364 (the decision 7 revision) also rewrites 0071's status line; whichever of the two lands second rebases that one line.

[gedaiu]

Thank you for the careful read. Both are fixed: the class note in 0071 is now its own paragraph with a blank line before it, and the may_attach comment is in Chinese. I'll rebase the status line if #1364 lands first.

[WaylandYang]

Both points are done. One more step before it can land: #1364 merged into dev a few minutes ago and touches 0071 at the same two places. Please rebase and resolve as follows:

• Status line: In progress · 2026-10-19 · #1293 · open: decisions 5, 6 and 7, and the name_vectors::pending skip of decision 4 (the README row stays In progress, as you have it).
• A same verdict that touches an identity entity waits for a person, so a small model cannot merge a source's identities (#1248) #1364 inserts decision 7 right after the - **Off:** bullet, where your "A NULL-typed holder keeps its class for now" paragraph now sits. Keep that paragraph out of the list: put it after decision 7 (before ## Not doing), or under decision 3, which it is really about.

With that it merges.

[gedaiu]

Thank you. Merged dev in and resolved 0071 as you described. The status line says open: decisions 5, 6 and 7, and the name_vectors::pending skip of decision 4, and the NULL-typed holder note now sits after decision 7, before ## Not doing.

[WaylandYang]

Thank you, every review point is done. #1251 landed just after your merge, so this conflicts again. In extraction_open.rs, keep dev's evidence.get(&key).map(String::as_str) and add identity after it. Also, #1251 added type_id and exact_name to Candidate, so the holder query in resolve_identity_name now needs e.type_id, true AS exact_name in its SELECT. Git won't flag that one, but the lookup fails at runtime without it. Once CI is green, it merges.

[gedaiu]

I merged dev in to clear a conflict with #1251. It changed the same call in extraction_open.rs and added type_id and exact_name to Candidate, so the holder query now selects both (exact_name is always true there). The store and server suites pass. Ready for another look whenever you have a moment, thank you!

[WaylandYang]

Thanks, both are in: the holder query selects type_id and exact_name, and the resolve_handle call keeps dev's evidence argument with identity added. CI is green. It merges after the PRs already queued ahead of it.