#4796 "A record the operator names by number reaches auto-inject only if
its wording happens to match". "yes go ahead with 4448" says which record
is meant, but a number means nothing to an embedding, so the prompt menu
filled with records resembling the words around it.
- record_refs.named_record_ids reads the operator's raw prompt, never the
reply-enriched query:
- `#N`, unless the word before it marks another numbering (PR, CI, rule,
milestone, system, log...);
- a bare number of 3 or more digits that opens the message, follows a
reference word or continues a list one started;
- never a quantity ("300 seconds"), a date, version, path or fenced code.
- Each id is resolved through the ACL check; trashed or inaccessible ids
are dropped.
- A "Named in your message" block leads the menu: the kind, the System,
the name and the opening of the body, or the seen pointer if the record
is already on the ledger. It takes no share of top_k, and the semantic
lines leave those ids out.
- The block is booked under the new `named_ref` source, registered as an
unbidden lookup that is allowed to be quiet. A named id that also ranked
counts as suppressed in the auto_inject row, so #3668's identity holds.
- Named records now arrive even when the search finds nothing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sessions predicted the ids their next creates would get and wrote them into
plan bodies and reference notes before the records existed. The database
never collides; the sequence is shared by every session and user, so any
concurrent create took the guessed numbers and the references pointed at
someone else's records.
- create_records (new MCP tool) and start_planning(body=, steps=) create
their records in ONE transaction: insert, flush for the real ids, rewrite
{{ref:N}} / {{ref:milestone}} placeholders as #id "title", commit. No
prediction, no waiting, no stub records left behind when a batch fails.
Ids need not be consecutive and nothing depends on it.
- Every MCP create/update of a note, task or milestone refuses a #N sitting
just above the highest assigned id (within 50): that can only be a guess.
Refusal, not warning. Numbers far above the max (PRs, forge issues) pass.
- notes.build_note splits validation out of create_note so the batch
validates records exactly as a single create does.
- writing-plans and using-scribe say to pass steps up front and never write
an unassigned id; plugin version minted.
Integration test runs six concurrent batches and checks each resolves its
placeholders to its own records, and that a failing batch writes nothing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>