Idea: find targets in C# plans, like edit_document's { find } targets

[ilia-sokolov]

The agent tools let a plan name text directly: in edit_document, a target can be { "find": "Acme Corp" } instead of a paraId and expect, and an ambiguous match is refused with the candidates listed (FindTargetResolver). C# plans cannot do this. A C# caller has to run FindAsync, pick a hit, and pass its anchor into the operation.

In the round-3 agent trial, that find-then-anchor step was where most C# integration time went: 4 of 16 first builds failed on the shape of a find hit, and the headline task took a median 14 minutes against 3 to 4 minutes for hand-written Open XML SDK code. #19 (documentation) and #26 (FindHit.ParaId) address the immediate errors. This idea goes further.

The idea

A find target usable in any C# plan, resolved when the plan is previewed and committed:

new ChangeTextOp
{
    Target = new FindTarget("thirty days"),   // name to be decided
    With = "forty-five days",
    Mode = ChangeMode.Tracked
}

It would follow the agent tools' rules: exactly one match or a refusal listing the candidates, an optional zero-based match index, and the same drift protection as today's anchors.

Questions

1. Is this worth new API surface in 1.x, or should the next agent trial first show whether Show what a find hit contains in getting-started #19 and Add FindHit.ParaId #26 are enough?
2. Should resolution move from OfficeAgent.AgentFramework into OfficeAgent.Core, so the agent tools and C# plans share one implementation?
3. How should a stored plan with a find target behave if the document has changed since it was written?

Not scheduled. Reactions and use cases will decide whether it becomes an issue.