Reachable Techniques for a Rack
reachable_techniquesGiven a rack (the module ids the user owns), return which canonical patch techniques the rack can realize, and which it is one module away from. The set-level companion to find_role_realizations: where that answers "which module fills role R in technique T?", this answers the rack owner's actual question — "given everything I own, what can I actually do, and what am I close to?".
This is the right tool the moment a user gives you their modules and asks an open "what can I do / what can this rack do / what am I missing?" question — instead of guessing techniques from training priors or calling find_role_realizations technique-by-technique by hand. It runs the affordance match across the whole technique catalog for you.
Returns two buckets:
reachable: every required role has a rack module that fills it. Each carries an
assignment(role → module).requires_shared_module: trueflags a technique only reachable by reusing one module for two roles — verify those roles can share one instance.near_misses: all-but-one role fillable;
missing_rolesnames the unfilled role(s) and therequired_affordancesyou'd need. This is the acquisition signal — "you can already do X; you're one module away from Y".
Args:
rack (string[], required): module ids, e.g. ["make-noise/maths", "mutable-instruments/plaits"]. Max 64. Ids that match no module are returned in
unresolved(with did-you-mean), not silently dropped.limit (number): max techniques per bucket. Default 25, max 100.
Stateless-rack contract: the server keeps no memory of your rack between calls — pass the COMPLETE current rack every call. A partial rack silently narrows what's reported reachable, so if a module id doesn't resolve, surface the unresolved did-you-mean to the user rather than proceeding on the incomplete set.
Scope: reachability is role-PRESENCE based. It does NOT verify per-role instance counts (cardinality) — a technique needing two independent envelopes is judged reachable if you have one envelope source. The distinct-instance question (can one module fill two roles?) is surfaced as requires_shared_module, not silently assumed. For the editorial detail on a specific technique (canonical instance, counter-canonical notes, full realization list), call list_techniques; for one role's candidates, find_role_realizations. To go the other way — which of your modules are redundant / safe to sell — call rack_redundancy.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| rack | Yes | ||
| limit | No |