Summary
Techniques in this corpus are meant to be atomic. Each one takes its declared inputs, does one thing over tools and resources, and hands back its declared outputs. When work needs two operations in sequence, the activity YAML binds them as two consecutive steps — the activity is where composition happens, and the bind sites are what the guard suite can read.
In 102 places across 74 technique files, a technique's own Protocol instead says Apply [some-other-operation] and carries on. The technique is doing the composing, and the activity that bound it cannot see that a second operation runs.
Found during the corpus-wide canon audit (#582), which fixed six other classes and left this one for its own decision. Nothing here is broken today — this is about where the wiring lives and what can check it.
What happens today
The clearest example is the GitHub group. Seventeen of github-cli-protocol's leaf operations — create-pr, view-issue, list-prs, assign-issue, and the rest — open with the identical line:
1. Apply [resolve-repo-coordinates](./resolve-repo-coordinates.md).
That helper reads git remote get-url origin from a named working tree, or splits the session's repository binding, and yields an owner and a repository name that the leaf then drops into its REST path. It is a small, pure derivation with no side effects, and the group's container contract already declares the two inputs it feeds on.
The same shape recurs elsewhere. Eleven operations in gitnexus-operations reach a sibling for their raw graph result — several apply detect-changes to get a changed-symbol set, several apply cypher to run a query. Three in harness-compat apply resolve-harness-operation to pick the right adapter before spawning, resuming, or running concurrent agents. workflow-engine has seven, and version-control, orchestration-patterns, and atlassian-operations one each.
It is not confined to meta. Of the 74 technique files carrying an Apply, 42 are in meta and 25 in work-package, with the remainder in workflow-design, prism-update, work-packages, midnight-system-review, and codebase-wiki.
Why it matters
The composition is unreadable from the activity. Someone reading workflow-design/activities/09-validate-and-commit.yaml sees one step that opens a pull request. They cannot see that a git command runs against a working tree first, or which working tree it runs against.
More concretely, it sits outside every mechanical check the repo has. The binding-fidelity guard verifies that step bindings resolve, that arguments conform, that reads have producers and outputs have consumers — all by reading bind sites in YAML. An Apply inside a Protocol is prose. So there is a whole layer of operation-to-operation wiring in this corpus that no guard covers, and the canon's answer is to move it to where the guards already look.
Why the fix is not obviously worth it
Binding a GitHub operation stops being one step and becomes two. A caller who forgets the resolve step gets an operation with no owner and no repository — a new way to be wrong that does not exist today, because today the operation cannot be invoked without its own first phase running.
Multiply that across the class. Every fix is a contract change to the technique — the values the Apply produced become declared inputs — plus an edit at each of that technique's bind sites. For the GitHub group alone that is 17 technique files and 12 bind sites.
There is also a real argument that some of these are not defects. All seventeen GitHub cases are one operation reaching a shared helper for a derived value it needs to do its own job, which is close to the "one produce path over tools and resources" that pass-orchestration-in-technique explicitly protects — except the carve-out says "with no Protocol Apply", so the literal text catches them. Against amending the entry: the same reasoning would excuse most of the 102, and the entry exists precisely because this wiring is what no guard can see.
Scope
Stage 1 — survey. Produce the inventory: all 102 sites, each with its applying technique, its target, and the bind sites a fix would touch. Classify each into one of three kinds — a shared helper returning a derived value inside its own group; genuine multi-operation sequencing that belongs in activity steps; and a facade whose whole Protocol is Apply lines. The three want different answers, and no decision on the class is sound before the split is known.
Stage 2 — decide per kind. For helpers, choose between hoisting them to activity steps and writing a carve-out narrow enough to cover a same-group, side-effect-free, value-returning Apply without excusing sequencing. For sequencing and facades, the canon's answer already stands and the question is only ordering.
Stage 3 — execute in slices, one group per pull request. github-cli-protocol first if the decision goes toward hoisting: it is the largest single pattern, the most uniform, and it proves the cost on real callers before anything else moves.
Acceptance criteria
- The inventory exists as a planning artifact, covering all 102 sites with the three-way classification and the bind sites each would touch.
- A decision is recorded for each kind, with its rationale, in the planning record.
- Where the decision is to hoist, every converted technique declares as inputs the values its Apply used to produce, and every bind site supplies them.
- Where the decision is a carve-out, the entry's Do-not-flag states the boundary in terms that leave genuine sequencing flagged, and the audit re-run confirms the remaining sites still surface.
- The guard suite stays green at every slice, and the option-coverage walk runs on any slice that changes a step list.
Non-goals
- Changing what any workflow does at runtime. Every conversion is a relocation of where the composition is declared.
- Touching the six classes already fixed in #582.
- Resolving the 28 decisionless checkpoint gates, which is a separate finding from the same audit.
Investigation detail
Counts are from the corpus at 131e2942c15cbcf16680980be7e15b107abf051d, taken by scanning every Apply [ occurrence in technique markdown under workflows/. Per-workflow file counts: meta 42, work-package 25, workflow-design 2, prism-update 2, work-packages 1, midnight-system-review 1, codebase-wiki 1. Per-group counts inside meta: github-cli-protocol 17, gitnexus-operations 11, workflow-engine 7, harness-compat 3, version-control 1, orchestration-patterns 1, atlassian-operations 1.
🤖 Generated with Claude Code
Summary
Techniques in this corpus are meant to be atomic. Each one takes its declared inputs, does one thing over tools and resources, and hands back its declared outputs. When work needs two operations in sequence, the activity YAML binds them as two consecutive steps — the activity is where composition happens, and the bind sites are what the guard suite can read.
In 102 places across 74 technique files, a technique's own Protocol instead says
Apply [some-other-operation]and carries on. The technique is doing the composing, and the activity that bound it cannot see that a second operation runs.Found during the corpus-wide canon audit (#582), which fixed six other classes and left this one for its own decision. Nothing here is broken today — this is about where the wiring lives and what can check it.
What happens today
The clearest example is the GitHub group. Seventeen of
github-cli-protocol's leaf operations —create-pr,view-issue,list-prs,assign-issue, and the rest — open with the identical line:That helper reads
git remote get-url originfrom a named working tree, or splits the session's repository binding, and yields an owner and a repository name that the leaf then drops into its REST path. It is a small, pure derivation with no side effects, and the group's container contract already declares the two inputs it feeds on.The same shape recurs elsewhere. Eleven operations in
gitnexus-operationsreach a sibling for their raw graph result — several applydetect-changesto get a changed-symbol set, several applycypherto run a query. Three inharness-compatapplyresolve-harness-operationto pick the right adapter before spawning, resuming, or running concurrent agents.workflow-enginehas seven, andversion-control,orchestration-patterns, andatlassian-operationsone each.It is not confined to
meta. Of the 74 technique files carrying anApply, 42 are inmetaand 25 inwork-package, with the remainder inworkflow-design,prism-update,work-packages,midnight-system-review, andcodebase-wiki.Why it matters
The composition is unreadable from the activity. Someone reading
workflow-design/activities/09-validate-and-commit.yamlsees one step that opens a pull request. They cannot see that a git command runs against a working tree first, or which working tree it runs against.More concretely, it sits outside every mechanical check the repo has. The binding-fidelity guard verifies that step bindings resolve, that arguments conform, that reads have producers and outputs have consumers — all by reading bind sites in YAML. An
Applyinside a Protocol is prose. So there is a whole layer of operation-to-operation wiring in this corpus that no guard covers, and the canon's answer is to move it to where the guards already look.Why the fix is not obviously worth it
Binding a GitHub operation stops being one step and becomes two. A caller who forgets the resolve step gets an operation with no owner and no repository — a new way to be wrong that does not exist today, because today the operation cannot be invoked without its own first phase running.
Multiply that across the class. Every fix is a contract change to the technique — the values the Apply produced become declared inputs — plus an edit at each of that technique's bind sites. For the GitHub group alone that is 17 technique files and 12 bind sites.
There is also a real argument that some of these are not defects. All seventeen GitHub cases are one operation reaching a shared helper for a derived value it needs to do its own job, which is close to the "one produce path over tools and resources" that
pass-orchestration-in-techniqueexplicitly protects — except the carve-out says "with no Protocol Apply", so the literal text catches them. Against amending the entry: the same reasoning would excuse most of the 102, and the entry exists precisely because this wiring is what no guard can see.Scope
Stage 1 — survey. Produce the inventory: all 102 sites, each with its applying technique, its target, and the bind sites a fix would touch. Classify each into one of three kinds — a shared helper returning a derived value inside its own group; genuine multi-operation sequencing that belongs in activity steps; and a facade whose whole Protocol is Apply lines. The three want different answers, and no decision on the class is sound before the split is known.
Stage 2 — decide per kind. For helpers, choose between hoisting them to activity steps and writing a carve-out narrow enough to cover a same-group, side-effect-free, value-returning Apply without excusing sequencing. For sequencing and facades, the canon's answer already stands and the question is only ordering.
Stage 3 — execute in slices, one group per pull request.
github-cli-protocolfirst if the decision goes toward hoisting: it is the largest single pattern, the most uniform, and it proves the cost on real callers before anything else moves.Acceptance criteria
Non-goals
Investigation detail
Counts are from the corpus at
131e2942c15cbcf16680980be7e15b107abf051d, taken by scanning everyApply [occurrence in technique markdown underworkflows/. Per-workflow file counts: meta 42, work-package 25, workflow-design 2, prism-update 2, work-packages 1, midnight-system-review 1, codebase-wiki 1. Per-group counts inside meta: github-cli-protocol 17, gitnexus-operations 11, workflow-engine 7, harness-compat 3, version-control 1, orchestration-patterns 1, atlassian-operations 1.🤖 Generated with Claude Code