Inline technique calls: composition inside a group, an activity step across one

[m2ux]

Summary

A technique file tells the assistant how to carry out one job, and partway through its instructions it will sometimes say to go and do what another technique file says. This work draws a line through those calls. Where the file being named sits alongside the caller in the same group — a folder of related operations sharing one declared set of inputs — the call stays as it is, because the group is composing itself and nothing outside it can see the arrangement. Where the call reaches out of the group, it becomes a step in an activity, because that is now the only boundary in the system where the values handed over are declared and checked.

There are 223 such calls, 87 of them inside a group and 136 leaving one. The 87 stay. The 136 are the population this work moves, checks, and then keeps out.

🐛 Issue 📐 Engineering

---

Motivation

The server that hands out technique files treats a sentence naming another file as ordinary text. It does not go and find the file, it does not compare the values being handed over against the ones that file declares it needs, and it does not deliver that file alongside the first. The assistant is given a path buried in the middle of a sentence and works out the rest on its own; where the path resolves to nothing, it either skips the instruction or improvises, and nothing in the run records which. That drift is already in the tree — renaming a technique, or changing the values it needs, reaches its callers silently. Eleven entries in the server's core-operations list exist only to compensate for the missing delivery by hand.

What changed while this was open

Two pieces of work landed on main that move the ground under it.

The first gives an activity a variable contract. An activity now declares the session values it reads and the values it writes, the writes are contributed to the workflow when the activity joins its graph, and a checker walks the graph for a read nothing writes, a write nothing reads, and a read that some path reaches before any write. 117 of the 122 activity files carry a contract and the check is green.

The second moves routing off the activities and into the workflow. An activity names its outcomes and nothing about what follows; the workflow file states where each outcome leads. Route declarations remaining in activity files: zero. That matters here because it changes the price of splitting an activity in two, which used to cascade into every workflow that borrowed it and is now an edit to one workflow file.

Together those two make the activity boundary the one place in the system where a value crossing between two units of work is declared, checked, and provably written before it is read. That is exactly what an inline call has always lacked. So the question stopped being how to make inline calls checkable and became which of them should exist at all.

The measurement that draws the line

Splitting the 223 calls by whether they cross a group boundary produces a result that had not been looked at before:

	calls	sites handing over a value the caller cannot supply
Alongside a sibling in the same group	87 (39%)	41
Reaching out of the group	136 (61%)	73

The sibling half is concentrated in the shared operation groups: the workflow engine's own operations call each other 27 times, the GitHub command-line group 17, the graph-query group 16, the Rust build group 6.

Those 87 must not move, and moving them would be worse than leaving them. An operation in a shared group is bound as a step by many different workflows. Hoisting a call it makes to one of its own siblings means every one of those workflows gains that sibling as a preceding step — the group's internal ordering published into a dozen workflow files, each holding a copy of a sequence it does not own. That is the same fault the routing work was written to remove, and paying it here to buy uniformity would be a poor trade.

The 136 crossings are the opposite case. Each one reaches a contract written somewhere else, with nothing binding the values and nothing checking them; 73 of them hand over a value the caller has no way to supply. Those are the calls the activity boundary can now take, and check.

One number from the original framing does not survive and is worth stating plainly. This was opened against 118 call edges across 554 technique files. That count reproduces under no counting rule that has been tried, varying by 59% across definitions of "a call" that read identically in prose. Acceptance is not keyed to it. It is keyed to the boundary rule, which needs to answer one question about each call — does it leave the group — and not to a precise total.

---

Changes

Stage one — the boundary rule. The checker compares the group the calling file belongs to against the group the called file belongs to. Staying inside is composition and passes. Leaving is a defect and fails. This replaces ten separate counting terms, each of which existed to bin and price calls precisely enough to deliver them; a boundary question needs none of that, and none of the coverage caveats that came with it. A call written in prose with no link still evades the check, as it always did, and the check says so rather than reporting clean over ground it never read.

Stage two — repair the crossings inside the groups. 41 sibling calls hand over a value the caller cannot supply. Each is fixed inside its own group, by adding the value to the group's declared inputs or to the calling operation's own signature. No consuming workflow is involved.

Stage three — move the crossings out. The 136 calls that leave a group become activity steps. The value each one carried becomes a variable the activity declares, so the load checks that something writes it and that the write precedes the read on every path. This is batched by group, largest first, and each batch is verified by a check that is already green on main.

Stage four — retire the delivery machinery. The walk that carried callee bodies to the caller, the three doors it rode on, the ledger entry that collapsed a delivered callee against a scheduled one, the block that attributed a callee's inherited rules to the calling site, and the two-plane counting that reported the same population on two bases — all of it existed to make a crossing work in place. A crossing that becomes a step does not need it. What is kept is the part that finds a link in a protocol and the part that compares two group names.

Stage five — the written authorities. The design canon, the construct inventory and the addressing specification currently disagree with each other and with the running server about whether these calls are legitimate at all. They are brought into agreement on the boundary rule: a call to a sibling is how a group composes itself, a call that leaves the group is an activity step.

Cross-workflow ancestry stays as delivered. A called technique takes its container contracts from its own home tree, applied identically at every resolution site — that is correct whether the call is delivered inline or bound at a step.

Core operations. The eleven hand-maintained entries compensating for the missing delivery are settled by the stage that serves each one: an entry standing in for a crossing retires when that crossing becomes a step, an entry standing in for a sibling call retires against the group that owns it, and an entry still unserved stays and is reported.

Acceptance

• Every call in a technique protocol either names a sibling of the caller's own group or does not exist; a call leaving a group fails the check.
• No sibling call hands over a value the caller cannot supply.
• Every value that used to cross a group boundary inside a protocol is declared by the activity that writes it and by the activity that reads it, and the graph walk finds a writer on every path.
• The count of calls leaving a group is stated before and after, and after is zero.
• The check states what it cannot see — a call named in prose with no link — rather than reporting a clean population.
• The three written authorities state the same rule as the checker.

Not in this change

The obligation to surface risk before an edit. One called operation requires its caller to put a high or critical risk finding to the user before proceeding. It crosses a group boundary and it depends on sitting next to the edit instruction, so as a separate step it has nowhere to live. It needs either a gate the server enforces or a rule on the group container, and that decision is open.

Composite activities, and an activity step whose operation the workflow supplies. These are what would let the repeated pre-check-and-post-check shape be declared once instead of copied per operation, and would give a value hoisted out of a protocol a scope narrower than the whole session. Both are named as unblocked by the routing work and neither is filed. They are the reason the crossings move as ordinary steps here rather than as a reusable wrapper.

Replacing an operation's prose with a typed tool call. Withdrawn before any file was edited, and tracked separately: the acceptance clause and the group's own rule requiring its operations be used cannot both hold.

---

📌 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

• Ready for review