Inline technique handling: calls between techniques resolve, get checked, and arrive as steps

[m2ux]

Summary

A technique file tells an agent how to carry out one job, and it sometimes tells the agent to go and do what another technique file says. The server reads that sentence as ordinary prose, so this work package makes the reference resolve, checks the values handed across it, and delivers the called file alongside the caller.

🐛 Issue 📐 Engineering

---

Motivation

When one technique file tells the agent to apply another, nothing follows that instruction through. The reference is not resolved, the values handed across are never compared against what the receiving file declares it needs, and the receiving file is never delivered — the agent is handed a raw file path in the middle of a sentence and improvises the rest. A survey of all 554 technique files found 118 of these calls. Ninety-nine of them, 84%, are invisible to the activity layer that schedules work, and 56 hand over fewer values than the file they call requires. Every link target exists, so nothing is dangling; the decay is entirely in the contracts, which is exactly the part nothing checks.

Left alone, this class of instruction keeps drifting quietly. Renaming a file, or changing the values it needs, reaches its callers with no warning, and instances of that drift are already in the tree — a caller passing a value under one name to a file that declares it under another, a wrapper that dropped one of its callee's three inputs. About ten entries in the server's core-operations list exist only to compensate for the missing delivery by hand, with nothing keeping them in step with the prose they mirror. One guard even points the wrong way: a technique reached only through an inline call looks unused, so the diagnostic blames the callee instead of the absent delivery path.

The rule that sorts these calls is already settled and recorded. A technique may call another technique when the result stays inside the calling technique's own work; the moment the workflow itself acts on the outcome — a gate reads it, a checkpoint presents it, a loop retries it — the call must become an activity step. The reasoning and the alternatives that were rejected are in the doctrine decision record.

---

Changes

Implementation (pending):

• A guard that resolves every inline reference through the same loader the server uses, and compares the values each call hands over against what the called file declares
• Two repairs alongside it: the resource scanner stops mistaking a plain sibling technique link for a resource id, and the unused-output check stops blaming techniques whose only callers are inline
• Loader support for the reference as structure rather than prose, so composition can deliver each called technique as its own marked step, in order, with cycle detection
• Removal of the hand-maintained core-operations entries once delivery is real
• The design canon, the construct inventory, and the addressing specification amended together, so every one of them states the same rule
• A disposition for each of the 118 call edges — moved to an activity step, kept as a checked call, or marked documentation-only

Scope within epic #397 is confirmed at requirements elicitation before implementation begins.

---

📌 Submission Checklist

• Changes are backward-compatible (or flagged if breaking)
• Pull request description explains why the change is needed
• Self-reviewed the diff
• I have included a change file, or skipped for this reason: [reason]
• If the changes introduce a new feature, I have bumped the node minor version
• Update documentation (if relevant)
• No new todos introduced

---

🔱 Fork Strategy

• Runtime Update
• Client Update
• Other
• N/A

---

🗹 TODO before merging

• Confirm scope within epic [Epic] Protocol Structure: Alternatives and Delegation the Server Can See #397 at requirements elicitation
• Implementation
• Address reviewer feedback
• Ready for review